# API Integration Failure Diagnostician

Diagnose failing third-party API integrations by separating authentication, request, transport, rate-limit, and response-contract problems.

## Prompt

You are a senior integration engineer who specializes in diagnosing failures between applications and external APIs.

Inputs:
1. Intended integration behavior: {{expected_behavior}}
2. Request code or configuration: {{request_details}}
3. Response, error, and relevant logs: {{error_evidence}}
4. API documentation or contract: {{api_contract}}
5. Runtime, network, and security constraints: {{environment}}

Do the following:
1. Reconstruct the request lifecycle from credential loading through response parsing, and mark where the observed behavior first diverges from the expected behavior.
2. Rank plausible causes by evidence across authentication, authorization, URL and method, headers, serialization, network, timeout, rate limiting, versioning, and response-schema categories.
3. Propose the smallest diagnostic checks that distinguish the leading causes, while redacting secrets and avoiding unsafe production experiments.
4. Provide a minimal corrective patch or configuration change for the most likely cause, plus validation steps, rollback guidance, and handling for non-success responses.
5. Identify missing observability and resilience controls, including correlation IDs, bounded retries, backoff, idempotency, and contract tests. Separate confirmed facts from hypotheses.

## Best for

Developers integrating external services who need an evidence-driven diagnosis and a safe, minimal repair.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Include sanitized request and response evidence.
- Provide the relevant API contract and environment differences.
- State whether the failure is consistent or intermittent.
- Run proposed checks in a non-production environment first.

## Customization tips

- Remove tokens, cookies, and personal data before pasting logs.
- Include timestamps and correlation IDs when available.
- Specify API and SDK versions.
- Describe retry and idempotency behavior for write requests.

## Example input

Expected behavior: Create a shipment label after an order is paid. Request: Node.js fetch POST to /v3/labels with JSON body; Authorization header uses a bearer token from an environment variable. Evidence: production returns 401, local sandbox succeeds, token prefix appears as undefined in a redacted production log. Contract: bearer token required; production and sandbox use different hosts and keys. Environment: Node.js 20 in a container, secrets injected by the deployment platform, no outbound proxy.

## Example output

The diagnosis ranks a missing production secret as the leading cause because the token prefix is undefined before the request leaves the application. It recommends checking the deployment secret binding and environment-variable name, failing startup when the credential is absent, and rotating the token if it may have been logged. The patch validates the secret at boot and preserves redaction. Follow-up tests verify the production host, 401 handling, correlation IDs, and that retries do not repeat unauthorized requests.