API schema drift detection and repair

Turn a third-party API change into an ordered integration repair plan

For integration engineers, platform teams, and SREs maintaining third-party APIs. Compare what your client previously expected with a current observation; receive breaking, degraded, or safe changes and the exact order in which to repair them.

Run the no-account demo Create a sandbox key

Free: 200 integration checks/month. Developer: $199/month with 5,000 included. Compare allowances and pricing.

Directional comparisonNo API key for demoNo autonomous code changes

Who this is for and when to use it

A payment provider made a request field mandatory and renamed a response field; existing calls now fail or deserialize incorrectly.

Best-fit team

Engineers responsible for external API clients, connectors, webhooks, or provider upgrades where contract drift can break production workflows.

Input

Your prior and current observations, including endpoint direction and flattened request/response fields. The service does not crawl or infer a provider contract for you.

Output

A verdict, breaking-change summary, directional change records, and repair steps ordered across auth, routing, outbound schema, inbound schema, webhook, and throughput phases.

Primary-value event

A successful authenticated POST /v1/checks returning drift classification and a machine-readable repair plan.

From the problem to a useful result

Choose the part of the review you need to solve

Find breaking request and response changes

API breaking-change detection starts with direction. Compare flattened request and response fields from prior and current observations to see which edits change the contract your client uses.

The existing example adds a required outbound field and renames an inbound field. Both are breaking in this sample; the representative response shows their distinct change records and proposed steps.

Review authentication, webhook and rate-limit drift

Integration drift can also affect required scopes, subscribed webhook events or throughput. Supply the relevant prior/current definitions and the usage context your integration relies on.

Held scopes, subscribed events and observed volume help interpret impact. Missing usage context does not establish that a change is safe. See the request reference before extending the small schema example.

Turn findings into an ordered repair review

During an API migration or incident review, inspect the verdict and evidence before acting on the repair plan. The returned steps carry action, phase, order, confidence and an automation flag.

In the sample, the new required value needs human input while the field rename has a mechanical mapping. autoApplicable describes a proposed step; this API does not apply or deploy the repair.

Check the integration again when it changes

Keep a prior capture and a current capture for each integration you maintain. Your release or maintenance process can call the comparison API and route findings to the engineer who owns the client.

Use the copyable example, then follow the verified account and key path for /v1/checks. Capture collection, source control and deployment remain in your existing workflow.

Compare the sample API captures Review pricing

Interactive keyless demo

Compare one fictional endpoint before and after drift

The example uses invented provider observations, runs the production comparison and repair engine, stores nothing, and consumes no account quota. Do not paste API credentials, captured customer payloads, or personal data.

Request bodyReady

JSON input

Schema source: the independently accepted Integration Recovery runtime example for /v1/demo/check. Previous must precede current when both use capturedAt.

Live response

Run the demo to see the unedited API response.

Look first at verdict and summary.breaking, then apply repairPlan.steps in ascending order. A demo call is evaluation, not a deployed connector or repaired production integration.

Copyable no-account path

Run the same check from a terminal

This block runs as written with curl. It contains only fictional API observations and no placeholder credential.

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}]}]}}}'

Expected contract-shaped result

What first useful value looks like

Representative response

{
  "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"
}

Request IDs can vary. The verdict, change direction, repair action, phase, order, confidence, and automation fields are the runtime result shape used by this example.

First useful result

verdict: broken shows that the integration is unsafe to run unchanged. The first repair adds a required outbound field and needs a human-supplied value; the second maps a renamed inbound field and is mechanically applicable.

Interpretation

autoApplicable describes whether a step can be applied without an information-losing guess. It is not permission for this API to edit or deploy your integration.

Authenticated first-value path

Verify the account, claim the key once, then run the metered check

Request a product-scoped key.
Replace only you@example.com. The source tuple identifies this exact-intent page; upstream UTM values are also carried by the signup CTA.
Open the verification email and claim its one-time token.
Replace only PASTE_ONE_TIME_TOKEN_FROM_EMAIL; capture the API key from the claim response.
Call /v1/checks with the bearer key.
A successful verdict and repair-plan response is the primary-value event. Key issuance by itself is not activation.

curl -sS -X POST https://integrationrecovery-api.com/v1/keys \
  -H 'content-type: application/json' \
  -d '{"email":"you@example.com","source":{"source":"product_site","medium":"exact_intent","campaign":"search-integration-recovery-exact-intent-v1","content":"api-schema-drift-detection-and-repair-v1"}}'

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'

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}]}]}}}'

After the example works

Add one observable contract comparison to an existing integration workflow

Capture one provider surface twice.
Preserve direction: request fields are outbound; response and webhook fields are inbound. Timestamp the prior and current observation.
Route repair steps by phase and automation flag.
Apply in ascending order. Send any autoApplicable: false step to an engineer with its change evidence and confidence.
Re-run the comparison after the reviewed change.
Your source control, tests, deployment, and rollback stay authoritative. The API produces a plan; it does not edit code or deploy repairs.

Troubleshooting

The three most likely blockers

401 unauthorized

Use the API key returned once by /v1/keys/claim, not the email claim token. Send it exactly as Authorization: Bearer $KEY.

400 invalid_request or client-side 422

Send exactly one check or a non-empty checks array. Every check needs integrationId, provider, previous, and current; field observations need path, type, and required.

429 rate limited

Read Retry-After when present, wait, then retry with bounded exponential backoff. Keep one stable integration identifier per logical integration.

Need support?

Record the stable error.code and request ID. Share the request ID only—never a key, claim token, provider credential, or captured customer payload.

Pricing and included usage

Choose a plan for recurring integration checks

One integration check compares one pair of snapshots. Endpoints, fields and webhooks within that pair do not each count as separate checks; a batch of 50 checks uses 50 units.

Free

$0/month

200 integration checks/month

No card required. The keyless demo consumes no account quota.

Developer

$199/month

5,000 integration checks/month included

$0.08 per additional integration check. Overage charges capped at $400 per billing period, in addition to the base price.

Growth

$1,999/month

75,000 integration checks/month included

$0.05 per additional integration check. Overage charges capped at $4,000 per billing period, in addition to the base price.

Scale

$4,999/month

300,000 integration checks/month included

$0.03 per additional integration check. Overage charges capped at $10,000 per billing period, in addition to the base price.

Prices in USD, billed monthly. Choose a plan for the volume you expect to run. See full pricing and Enterprise options.

Create a key to check your integration Review the input contract

Trust, privacy, and limits

A repair plan is an explainable recommendation, not an autonomous production change

The keyless demo processes the supplied payload without storing or metering it. Authenticated use is governed by the privacy policy and terms. Submit contract observations, not API keys, bearer tokens, raw customer payloads, or provider secrets.

The API does not fetch provider documentation, replay failed deliveries, modify code, execute a repair, or deploy an integration.
The OpenAPI request/response correction and regenerated Python and TypeScript SDKs were released on September 7, 2026. The direct HTTP example uses that comparison contract; provider onboarding, certification and listing are separate processes.
No customer or revenue result is claimed. A live page, demo run, marketplace listing, signup, key, or synthetic test is not commercial validation.

Create a sandbox key Read the API reference