API Contract Change Alerts: An Issue When a Vendor Response Changes Shape

Last verified on Nov 10, 2026.

What it catches

An API contract is what the other side agreed to send. When it changes without notice, your code often keeps running and does the wrong thing. The Sazabi agent sets up sensors for your project, and Contract change is one of them, set up for the vendors your code calls. It looks for:

• A field your code relies on that begins to arrive empty or null.
• A value that changes type, such as a number that is now a string.
• A new required field or enum value that your code logs as unexpected.
• A response that used to be a single object and is now a list.
• An error body in a new format, so your handler logs "could not parse" for every failure.

None of these throw an HTTP error. The vendor still returns 200.

Example: a field starts arriving empty

This is an example, not output from a real project. Your invoicing service reads a tax identifier from a billing vendor and logs a warning when it is missing.

2026-11-08T11:07:31Z INFO  invoicing fetched customer vendor=billing-api customer=c_4410 tax_id=DE811234567
2026-11-08T11:52:03Z WARN  invoicing customer has no tax_id vendor=billing-api customer=c_4977 status=200
2026-11-08T11:52:09Z WARN  invoicing customer has no tax_id vendor=billing-api customer=c_5012 status=200
2026-11-08T11:52:41Z ERROR invoicing cannot issue invoice: tax_id required customer=c_5012

A sensor for this might ask: "Tell me when the share of billing vendor responses with no tax ID goes above its usual level." A line like "cannot issue invoice: tax_id required" should never appear, so even the first one is worth investigating.

An example issue:

• Name: Billing vendor responses missing tax_id since 11
  UTC
• Description: Customer lookups return 200 with an empty tax_id for accounts that had one before. Invoices fail for every affected customer.
• Severity: high
• Component: invoicing

How Sazabi sets it up

You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time. It finds the vendors you call, the fields you log from their responses and the warnings your own code emits when a response looks wrong. Some questions are about a share or a count of responses, such as how many have no tax ID. Others are about lines that should never appear. The agent writes, backtests and maintains these sensors as you change the integration.

You do not upload schemas or specs.

What you see and how you get told

The issue names the vendor and field, shows evidence from your logs and states when the change began. It arrives investigated, so the analysis already compares the new responses with earlier ones. You hear about it through your notification settings, or through a delivery rule that sends issues for a component to its team channel.

In the thread, ask which customers were affected or which release of your integration was running. When you are ready to adapt the code, sazabi issues agent-prompt produces a prompt for a coding agent. Underlying signals show up with sazabi signals list --type sensor.

What it does not cover

• It does not compare an OpenAPI document or SDK version. Dependency change is not covered today.
• It cannot detect a change your code neither logs nor reacts to.
• It does not notify you of a vendor's announced deprecations.
• A vendor that gets slow or throttles you is a separate signal.

Related

Start with vendor degradation when responses are late instead of different. For the sibling signal on your own events, read the guide to field drift. Wrong counts across systems belong to reconciliation mismatches. Connect more sources from the integrations list, and see pricing for issue billing.