Watching vendor API changes: OpenAI, Stripe, Twilio and GitHub compared

Every vendor tells you about API changes somewhere. The somewhere is different for each of them, the notice periods differ, and none of the channels is a push notification to your CI. This article compares four vendors a typical integration stack touches, using their own documentation pages as read on 2026-10-08, and then runs a real check against two of them.

The four models at a glance

• GitHub: date-named API versions, chosen per request with a header. The previous version is supported for at least 24 more months.
• Stripe: an account default version, overridable per request. Monthly releases with no breaking changes, a major release twice a year.
• OpenAI: no version to pin. A deprecations page with minimum notice periods.
• Twilio: a core API under a fixed 2010-04-01 path. Changes arrive through the changelog and migration guides.

GitHub: dated versions and a written list of what counts as breaking

GitHub's API versions page says the REST API is versioned and that each version is named for its release date. You choose one with the X-GitHub-Api-Version header. Requests without the header default to 2022-11-28, and the page lists two supported versions today: 2026-03-10 and 2022-11-28. When a new version is released, the previous one is supported for at least 24 more months.

The same page enumerates what GitHub counts as breaking:

• Removing an entire operation
• Removing or renaming a parameter or a response field
• Adding a new required parameter, or making an optional one required
• Changing the type of a parameter or response field
• Removing enum values
• Adding a new validation rule to an existing parameter
• Changing authentication or authorization requirements

Additive changes (new operations, optional parameters, response fields, enum values) are available in all supported versions. So a pinned header does not freeze what you receive: a response can gain a field or an enum value at any time.

Stripe: an account default, a header, and twice-yearly major releases

Stripe's versioning reference describes the release process it has followed since 2024-09-30.acacia: new API versions monthly with no breaking changes, and twice a year a major release (their example is Basil) that starts with a version containing breaking changes. Requests use your account's default version unless you send a Stripe-Version header. Webhook events also use the account default unless you set a version when you create the endpoint.

The upgrades guide adds two details that matter for monitoring. Server-side SDK calls use the API version that was current when that SDK was released, and in a strongly typed language such as Java, Go or .NET you cannot target a different one. And Stripe points to its developer changelog as the complete record of changes. The current version, 2026-09-30.endive, has two entries removing the payment method types parameter: one for Checkout Sessions, one for Payment Intents and Setup Intents.

Stripe also documents its enums as closed or open. An open enum can gain values as a backward-compatible change, without an API version upgrade, and Stripe's guidance is not to assume the documented values are exhaustive.

OpenAI: no version to pin, so the deprecations page is the contract

OpenAI's deprecations page states the lifecycle: affected customers are emailed and the deprecation is listed in the documentation. The minimum notice it gives is six months for generally available models, three months for specialized model variants, and potentially as little as two weeks for preview models. There is no dated account version to hold you in place, so the defensive question is different: what did current just become?

Twilio: a quiet specification and a busy changelog

Twilio's changelog and migration guides carry its changes. One example from the API domain migration guide: Twilio says the regional pattern api.REGION.twilio.com (for example api.ie1.twilio.com) processes all requests in US1 regardless of the region code and will stop working on April 28, 2026.

Twilio is also the instructive negative case for spec monitoring. Over the six months we measured, the specification for its api_v2010 surface had 197 operations before and 197 after, with nothing removed and nothing deprecated. A monitor over that document would have nothing honest to report, which is why apibreak deliberately does not support it. A quiet specification does not mean a quiet vendor. It means the specification is the wrong channel for that vendor, and the changelog is the right one.

Which channel can a machine read

A changelog is written for people and arrives as prose. All four vendors also publish an OpenAPI description of their REST surface in a public repository with commit history: github/rest-api-description, stripe/openapi, openai/openai-openapi and twilio/twilio-oai. That is the channel where a program can ask a precise question: did any operation my code calls change shape between revision A and revision B, and did any gain the deprecated flag?

How much that question returns depends on the vendor. Our six-month GitHub measurement (2026-03-26 to 2026-09-25) saw the description go from 1,107 operations to 1,224, with 142 added, 25 removed and 7 newly marked deprecated. Twilio's returned nothing, as above.

A worked example, run on 2026-10-08

Declare the endpoints you call per vendor, with a baseline you pin. This manifest names one GitHub read and one Stripe write:

{
  "version": 1,
  "integrations": [
    {
      "vendor": "github",
      "baseline": "2026-03-26",
      "endpoints": ["GET /repos/{owner}/{repo}/issues"]
    },
    {
      "vendor": "stripe",
      "baseline": "2025-08-19",
      "endpoints": ["POST /v1/checkout/sessions"]
    }
  ]
}

We ran it with apibreak on 2026-10-08. The Stripe baseline date resolved to 2025-08-27.basil and was compared with 2026-09-30.endive. The summary line and the findings, shortened:

4 breaking, 3 advisory, 6 not compared. 2 endpoints checked,
141 additive changes not listed.

breaking  stripe  POST /v1/checkout/sessions
  request  ui_mode no longer accepts custom, embedded, hosted
  request  line_items[].dynamic_tax_rates no longer in the schema
  request  payment_method_types no longer in the schema
  response line_items.data[].discounts[].discount.coupon
           no longer in the schema

advisory  github  GET /repos/{owner}/{repo}/issues
  response issue_field_values[].data_type may now return
           multi_select

advisory  stripe  POST /v1/checkout/sessions
  response ui_mode may now return elements, embedded_page,
           form, hosted_page
  response line_items.data[].taxes[].rate.tax_type may now
           return 4 new values

Three things in that output are worth reading closely. The payment_method_types row is the same removal the endive changelog describes in prose, found without anyone reading the changelog. The GitHub endpoint had no breaking finding, only a new enum value on a response, which is exactly the additive drift GitHub says can land in any supported version. And six parts of the two schemas were not compared (mostly anyOf and oneOf unions); the report lists them on every run instead of passing them silently. The run exits with code 2 because a breaking finding is present, which is what fails the CI job.

A monitoring policy per vendor

1. GitHub: send X-GitHub-Api-Version explicitly. Diff the published description against a pinned baseline weekly for the operations you call, and treat newly deprecated operations as warnings.
2. Stripe: set an explicit API version in code instead of relying on the account default, as Stripe's upgrade guide advises. Diff your pinned version against the target before upgrading. Give every open enum you parse a fallback branch.
3. OpenAI: there is no version to pin, so fetch the deprecations page and changelog on a schedule, and diff openai-openapi between commits for operations that gain the deprecated flag.
4. Twilio: watch the changelog and migration guides, and search your code for hardcoded regional domains. Do not expect a weekly signal from a spec diff.

The general rule falls out of the comparison: match the channel to the vendor's versioning model. Where you pin a version, a spec diff answers an upgrade-impact question. Where you cannot pin, it is an early warning. And where the specification barely moves, the changelog is the only sensor.