Skip to Content
๐Ÿ“ Partner Provider๐Ÿ“„ Provider Console

Provider Console

The Provider Console is the home screen for an onboarded partner. It answers a different question from the consumer screens: how many teams use me, and how do I ship a change to all of them at once? A partner publishes a change here once, and API Sync turns it into validated PRs across every consumer using that provider, without ever reading the consumerโ€™s source code.

What it does#

Acting as a provider. A selector at the top chooses which partner provider the console is acting as, and the page header, icon, and numbers follow that choice. The selection is remembered so you return to the same provider.

Adoption at a glance. Four tiles summarize the provider: consumers using you, open changes, published changes, and latest API version. These are the numbers a provider cares about when deciding what to ship and when.

Published changes. A panel lists the changes this provider has already published, each with its title, how many consumers it impacts, when it went out, and its change type. An empty list points you to the Publish change button.

Publishing a change. The โ€œPublish changeโ€ button opens a four-step wizard:

  1. Pick the provider and the change type (breaking, deprecation, security, new feature, or non-impacting), and give it a title.
  2. Describe the affected surface: methods, deprecated fields, replacement fields, and webhook events.
  3. Write the migration rule (the deterministic transform, plus context for the AI codegen) and a link to the migration guide.
  4. Set the version range and the effective or end-of-life date.

On submit, the change becomes a structured migration pack, and API Sync reports how many consuming companies it impacts.

How it behaves#

Impact is computed on the server. When you publish, the backend matches the change against every consumer inventory that uses this provider and returns the impacted-company count. The number comes from real detected usage across consumers, not an estimate typed in by the author.

Providers cannot see consumer code. A partner publishes structured facts about their own change: methods, fields, versions, a transform rule. API Sync applies that across consumers on their side. The provider console never exposes any consumerโ€™s source, only how many are affected.

The wizard guards its own submit. The Publish button on the final step is disabled until there is a title and a valid provider, and it shows a โ€œPublishingโ€ state while the request is in flight. Success and failure both surface as a toast, with the real error message on failure.

Only partners publish. The publish wizard offers only providers whose source is โ€œpartner.โ€ A platform-maintained provider has its records inferred from public data instead, so it does not appear as a publishing target here.

Data flow. The console reads useListProvidersQuery for the provider set and useListChangesQuery for that providerโ€™s published changes. Publishing is usePublishChangeMutation over POST /v1/api-sync/changes, which invalidates the changes, providers, and dashboard caches so every affected screen updates.

Was this page helpful?
Provider Console | apisync