API Versions

API Versions is the record of everything a partner has published for a provider: the change records and best-practice rules, what each one changed, and the migration path to it. It is the library that the consumer-side machinery draws on when it matches changes against detected usage.

What it does#

A table of published records. Each row shows the version, the change title, its kind, its source, and when it was released. Two kinds appear:

• Change record is a specific change to migrate to, tied to a version.
• Best practice is a standing rule that flags outdated or risky usage regardless of any single change.

Two sources, clearly separated. The Source column tells you where a record came from:

• Partner-authored records are authoritative. The provider wrote them.
• Platform-pulled records are API Sync’s inference from public data (specs, SDK releases, changelogs) for providers who have not onboarded as partners.

A detail drawer. Clicking a row opens the full record: its kind and source as chips, a summary, the transform rule shown as code, any migration rules with their before-and-after, and an “applies to” note. That note is the important part: a record applies to any consumer whose inventory matches the affected methods, and it runs on connect as a usage review and on provider change as a migration.

Publishing a version. A “Publish version” button opens the same change-authoring wizard used on the Provider Console, so new versions can be added from either screen.

How it behaves#

Authoritative versus inferred is a first-class distinction. The partner-authored and platform-pulled labels are not cosmetic. They tell a consumer how much to trust a record. Partner-authored records come straight from the provider; platform-pulled ones are API Sync’s best reading of public data until the provider onboards. The screen never blurs the two.

Scoped to the selected provider. Like the Provider Console, this screen acts as one provider at a time, chosen with the provider selector, and the table shows only that provider’s records.

Records are structured, so they can be applied. Each record carries a machine-readable transform rule and optional migration rules with file patterns, which is what lets API Sync apply the change to consumer code. The summary and guide URL are for humans; the rule is for the codegen.

Data flow. The table is useListChangesQuery scoped to the selected provider, over GET /v1/api-sync/changes. Publishing a version reuses the same POST /v1/api-sync/changes mutation as the Provider Console, so both screens stay consistent.