# API Onboarding Diagnostician

> Analyze API request/response logs from a failing enterprise customer onboarding and produce a root-cause diagnosis with a fix path. Use this skill whenever the user mentions API onboarding failures, integration errors during go-live, 4xx/5xx patterns in customer logs, webhook delivery failures, or pastes API logs and asks why an integration is failing, even if they only say "customer is blocked."

- Skill: `prashanthvara/api-onboarding-diagnostician` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add prashanthvara/api-onboarding-diagnostician`
- Raw SKILL.md: https://api.skillmd.com/api/skills/prashanthvara/api-onboarding-diagnostician/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: Prashanthvara (https://skillmd.com/u/prashanthvara)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/prashanthvara/api-onboarding-diagnostician

---


# API Onboarding Diagnostician

Turns raw API logs from a stuck onboarding into a root-cause finding, a fix owner, and a customer-facing status update, in one pass.

## Inputs

- API request/response log excerpt (JSON lines, HAR, or plain text)
- Integration context: which endpoints, auth method (OAuth2, API key, mTLS), expected flow

Synthetic log fixtures per failure class in `references/log_fixtures/`.

## Workflow

1. Run `scripts/parse_logs.py` to bucket entries by endpoint, status code, and error body signature.
2. Match the dominant signature against `references/failure_signatures.md`: auth (expired token, wrong grant type, clock skew on JWT), payload (schema drift, enum mismatch, encoding), rate limiting (429 with retry-after ignored), idempotency (duplicate key collisions), environment (sandbox credentials against production host).
3. Separate customer-side faults from platform-side faults. The fix path differs completely.
4. Draft two artifacts: an internal engineering ticket (signature, frequency, first occurrence, reproduction) and a customer-facing status note (plain language, next step, owner, ETA discipline: no ETA unless the fix owner committed one).

## Output format

`## Root Cause`, `## Evidence` (bucketed counts), `## Fix Path` (owner and change), `## Customer Update` (under 100 words, no internal jargon).

## Guardrails

- Never send the customer an update that attributes fault before the evidence supports it.
- Redact tokens, keys, and PII from all quoted log lines.