Skip to main content
Debug REST/GraphQL APIs: status codes, auth, schemas, repro.

Skill metadata

Reference: full SKILL.md

The following is the complete skill definition that Mibyan loads when this skill is triggered. This is what the agent sees as instructions when the skill is active.

API Testing & Debugging

Drive REST and GraphQL diagnosis through Mibyan tools — terminal for curl, execute_code for Python requests, web_extract for vendor docs. Isolate the failing layer before guessing at the fix.

When to Use

  • API returns unexpected status or body
  • Auth fails (401/403 after token refresh, OAuth, API key)
  • Works in Postman but fails in code
  • Webhook / callback integration debugging
  • Building or reviewing API integration tests
  • Rate limiting or pagination issues
Skip for UI rendering, DB query tuning, or DNS/firewall infra (escalate).

Core Principle

Isolate the layer, then fix. A 200 OK can hide broken data. A 500 can mask a one-character auth typo. Walk the chain in order; never skip a step.

5-Minute Quickstart

REST via terminal

GraphQL via terminal

GraphQL gotcha: servers often return HTTP 200 even when the query failed. Always inspect the errors field regardless of status code:

Python (requests) via execute_code

Layered Debug Flow

Step 1 — Connectivity

Failures: DNS not resolving, firewall, VPN required, proxy missing.

Step 1.5 — Timeouts

Distinguish can’t reach from reaches but slow:
In Python, always pass a tuple timeout — requests has no default and will hang forever:
Diagnosis: high time_connect is network/firewall; high time_starttransfer with low time_connect is a slow server.

Step 2 — TLS/SSL

Failures: expired cert, self-signed, hostname mismatch, missing CA bundle. Use -k only for ad-hoc debug, never in code.

Step 3 — Authentication

Checklist:
  • Token expired? (exp claim in JWT)
  • Right scheme? Bearer vs Basic vs Token vs X-Api-Key
  • Right environment? Staging key on prod is a classic
  • API key in header vs query param (?api_key=…)?

Step 4 — Request Format

Content-Type / body mismatch — the silent 415/400:
Common: form-encoded vs JSON, missing required fields, wrong HTTP method, unencoded query params.

Step 5 — Response Parsing

Always inspect content-type before calling .json():
Failures: HTML error page where JSON expected, empty body, wrong charset.

Step 6 — Semantic Validation

Parsed cleanly — but is the data correct?
  • Does "status": "active" mean what your code thinks?
  • ID in response matches the one requested?
  • Timestamps in expected timezone?
  • Pagination returning all results, or just page 1?

HTTP Status Playbook

401 Unauthorized — credentials missing or invalid

  1. Authorization header actually present? (curl -v to confirm)
  2. Token correct and unexpired?
  3. Right auth scheme? (Bearer vs Basic vs Token)
  4. Some APIs use query param (?api_key=…) instead of header.

403 Forbidden — authenticated but not authorized

  1. Token has the required scopes/permissions?
  2. Resource owned by a different account?
  3. IP allowlist blocking you?
  4. CORS in browser? (check Access-Control-Allow-Origin)

404 Not Found — resource doesn’t exist or URL is wrong

  1. Path correct? (trailing slash, typo, version prefix)
  2. Resource ID exists?
  3. Right API version (/v1/ vs /v2/)?
  4. Right base URL (staging vs prod)?

409 Conflict — state collision

  1. Resource already exists (duplicate create)?
  2. Stale ETag / If-Match?
  3. Concurrent modification by another process?

422 Unprocessable Entity — valid JSON, invalid data

The error body usually names the bad fields. Check:
  • Field types (string vs int, date format)
  • Required vs optional
  • Enum values inside the allowed set

429 Too Many Requests — rate limited

Check Retry-After and X-RateLimit-* headers. Exponential backoff:

5xx — server-side, usually not your fault

  • 500 — server bug. Capture correlation ID, file with provider.
  • 502 — upstream down. Backoff + retry.
  • 503 — overloaded / maintenance. Check status page.
  • 504 — upstream timeout. Reduce payload or raise timeout.
For all 5xx: backoff with jitter, alert on persistence.

Pagination & Idempotency

Pagination. Verify you’re getting all results. Look for next_cursor, next_page, total_count. Two patterns:
  • Offset (?limit=100&offset=200) — simple, can skip items if data shifts.
  • Cursor (?cursor=abc123) — preferred for live or large datasets.
Idempotency. For non-idempotent operations (POST), send Idempotency-Key: <uuid> so retries don’t double-charge / double-create. Mandatory for payments and orders.

Contract Validation

Catch schema drift before it hits production:
Run after API upgrades, when integrating new third parties, or in CI smoke tests.

Correlation IDs

Always capture the provider’s request ID — fastest path to vendor support:
Vendor bug-report template:

Regression Test Template

Drop this into tests/ and run via terminal('pytest tests/test_api_smoke.py -v'):

Security

Token handling

  • Never log full tokens. Redact: Bearer <REDACTED>.
  • Never hardcode tokens in scripts. Read from env (os.environ["API_TOKEN"]) or ${mibyan_HOME:-~/.mibyan}/.env.
  • Rotate immediately if a token surfaces in logs, error messages, or git history.

Safe logging

Leak checklist

  • Credentials in URLs. API keys in query strings end up in server logs, browser history, referrer headers — use headers.
  • PII in error responses. 404 on /users/123 shouldn’t reveal whether the user exists (enumeration).
  • Stack traces in prod. 500s shouldn’t leak file paths, framework versions.
  • Internal hostnames/IPs. 10.x.x.x, internal-api.corp.local in error bodies.
  • Tokens echoed back. Some APIs include the auth token in error details. Verify they don’t.
  • Verbose Server / X-Powered-By. Stack-info leaks. Note for security review.

Mibyan Tool Patterns

terminal — for curl, dig, openssl

execute_code — for multi-step Python flows

When debugging spans auth → fetch → paginate → validate, use execute_code. Variables persist for the script, results print to stdout, no risk of token spam in your context:

web_extract — for vendor API docs

Pull the spec for the endpoint you’re debugging instead of guessing:

delegate_task — for full CRUD test sweeps

Output Format

When reporting findings:
  • systematic-debugging — once the failing API layer is isolated, root-cause your code
  • test-driven-development — write the regression test before shipping the fix