Integration Recovery API

Detect auth, schema, webhook and rate-limit drift in third-party integrations and generate an ordered, machine-readable compatibility repair plan.

• Product and pricing
• Developer documentation
• Create a free account
• OpenAPI contract
• Postman collection

Quickstart: diagnose one integration drift without an account

This deliberately small demo runs the production comparison and repair engine, stores nothing, and requires no key.

curl -sS -X POST https://integrationrecovery-api.com/v1/demo/check \
  -H 'content-type: application/json' \
  -d '{"check":{"integrationId":"acme-payments-prod","provider":"northwind-payments","previous":{"capturedAt":"2026-05-01T00:00:00Z","endpoints":[{"method":"POST","path":"/v1/charges","request":[{"path":"amount","type":"integer","required":true}],"response":[{"path":"receipt_url","type":"string","required":true}]}]},"current":{"capturedAt":"2026-08-01T00:00:00Z","endpoints":[{"method":"POST","path":"/v1/charges","request":[{"path":"amount","type":"integer","required":true},{"path":"statement_descriptor","type":"string","required":true}],"response":[{"path":"receiptUrl","type":"string","required":true}]}]}}}'

The response classifies both changes as breaking and orders the repair work:

{
  "check": {
    "integrationId": "acme-payments-prod",
    "verdict": "broken",
    "summary": {"total": 2, "breaking": 2, "degraded": 0, "safe": 0},
    "changes": [
      {"code": "field_added", "surface": "request", "target": "statement_descriptor", "breaking": true},
      {"code": "field_renamed", "surface": "response", "target": "receipt_url", "to": "receiptUrl", "breaking": true}
    ],
    "repairPlan": {
      "steps": [
        {"change": 0, "action": "add_default_value", "phase": "outbound_schema", "order": 1, "target": "statement_descriptor", "confidence": 20, "autoApplicable": false},
        {"change": 1, "action": "map_renamed_field", "phase": "inbound_schema", "order": 2, "target": "receipt_url", "confidence": 95, "autoApplicable": true}
      ],
      "autoApplicable": 1,
      "requiresHuman": 1,
      "fullyAutomatic": false
    }
  },
  "requestId": "req_example"
}

That is the first useful result: verdict says whether the integration is safe to run, while repairPlan.steps says what to change and in what order. Step 1 needs a human-supplied default because autoApplicable is false; step 2 is an automatic response-field mapping because autoApplicable is true.

Create and use a free API key

curl -sS -X POST https://integrationrecovery-api.com/v1/keys \
  -H 'content-type: application/json' \
  -d '{"email":"you@example.com","source":{"source":"github","medium":"developer","campaign":"integration-recovery-github","content":"readme"}}'

curl -sS -X POST https://integrationrecovery-api.com/v1/keys/claim \
  -H 'content-type: application/json' \
  -d '{"token":"PASTE_ONE_TIME_TOKEN_FROM_EMAIL"}'

export KEY='PASTE_API_KEY_FROM_CLAIM_RESPONSE'

Use the same complete check under the authenticated endpoint for a metered integration check:

curl -sS -X POST https://integrationrecovery-api.com/v1/checks \
  -H "Authorization: Bearer $KEY" \
  -H 'content-type: application/json' \
  -d '{"check":{"integrationId":"acme-payments-prod","provider":"northwind-payments","previous":{"capturedAt":"2026-05-01T00:00:00Z","endpoints":[{"method":"POST","path":"/v1/charges","request":[{"path":"amount","type":"integer","required":true}],"response":[{"path":"receipt_url","type":"string","required":true}]}]},"current":{"capturedAt":"2026-08-01T00:00:00Z","endpoints":[{"method":"POST","path":"/v1/charges","request":[{"path":"amount","type":"integer","required":true},{"path":"statement_descriptor","type":"string","required":true}],"response":[{"path":"receiptUrl","type":"string","required":true}]}]}}}'

SDKs

• Python SDK — reads INTEGRATION_RECOVERY_API_KEY
• TypeScript SDK

The request shown here is a supported runtime example and has been checked against the deployed comparison engine. The OpenAPI document, generated SDKs, and production runtime now agree on the exactly-one-of check/checks input, closed repair parameters, response fields and nullability, evaluatedAt, rateLimit, and the 413 payload_too_large error envelope. Connector builders can use the published contract directly; the examples above remain the fastest way to confirm the first useful result.

Collection scope

The runnable Postman collection includes the public demo, the no-key checkout path, key bootstrap, and API-key product operations. It intentionally excludes the provider-only billing webhook and browser-session subscription, invoice, and payment routes: those require a signed hub request or the dashboard's HttpOnly session and CSRF controls, and a bearer API key cannot run them. The OpenAPI document linked above remains the reference for those operations.

Authentication and troubleshooting

• 401: set KEY to the value returned once by /v1/keys/claim.
• 400 invalid_request: send exactly one check (or a non-empty checks array), each with integrationId, provider, previous and current. A client-side schema tool may label the same input problem 422 before send.
• 429: wait for Retry-After when present, then retry with backoff.

Errors use a stable error.code and request ID. Share only the request ID with support, never customer contract captures, the API key or claim token.

Distribution attribution

The key request above uses the stable tuple github / developer / integration-recovery-github / readme. The Postman collection and SDKs carry their own source metadata. Attribution compares qualified activation and retained use; it does not claim that this channel already performs.

License

MIT