APISynQ documentation

APISynQ sits on both sides of an API. For APIs you publish, it shows who a change breaks before you publish it. For APIs you consume, yours or an external provider's like Stripe, it watches for changes and reacts the moment one ships.

Everything runs through one loop: a change is detected, the affected code is found in every dependent app, a fix PR is opened per app, and each fix is verified with that app's own tests. The number that matters at the end is time to all-green: how long from change detected to every affected app verified.

Connect your source code repositories. APISynQ scans them and builds your dependency graph: which apps call which APIs, at which call sites. No manual registration is needed to get the first graph; discovery comes first, and teams confirm what the scanner found.

From there, register the APIs you publish (spec, environments, versions) and the external providers you depend on. External specs are watched by polling; internal ones update on publish.

Producer and consumer are roles, not entity types: one app can be both. A relationship between a consumer app and a producer API is in one of these states:

• Discovered: the scanner found real call sites in code. Discovered relationships appear in the graph and in impact analysis whether or not anyone has confirmed them; code makes a dependency real.
• Declared: one side said the dependency exists, for example a consumer subscribing before writing code.
• Confirmed: both teams accepted the relationship. One click on each side; the scanner pre-fills what it proved. Contracts and publish gates hang off confirmed relationships.
• Watched: external providers like Stripe never confirm anything. Their APIs are watched, and their changes act as tripwire alerts rather than gates.

• Detect: every API you publish and every one you consume is watched. External specs by polling, internal ones on publish.
• Find: each diff is classified as breaking or safe, and affected call sites are located at file:line in every consumer.
• Fix: one PR per affected consumer, quoting the real call sites. Fixes cover deprecations and new-capability adoptions alike.
• Verify: the fix runs against the consumer's own tests, in their own CI. Nothing counts as migrated until the verified PR is green and merged.

Every PR is honestly labeled on two axes: why it exists, and how much proof it carries.

• Migration or adoption: a migration PR responds to a breaking change; an adoption PR shows how your code would use a newly shipped capability.
• Simple or verified: a simple PR is the scanned change, labeled "suggested change, not runtime-validated." It works day one with just the repository connection. A verified PR arrives with proof: the patched code was built, deployed against the producer's new endpoint, and your test collection ran green before the PR ever reached reviewers.

There is no middle state. A PR either carries the verified badge or it makes no runtime claim at all.

Consumers own what OK means. A 200 from the producer is not good enough: the producer can prove their API answers, not that your app still works. Verification runs your real scenarios and test cases.

A consumer's acceptance criteria is one test collection, one dataset, and one designated environment, targeting the consumer's own application. Validation is binary: green means verified for this change, anything else means not validated, stated plainly. A run that could not execute is reported as exactly that, never as a pass or a failure of the contract.

For changes the producer claims are backward compatible, the collection runs against your current deployment pointed at the new endpoint; a red run catches the de-facto breaking change before production. For breaking changes, the patched code and the new endpoint are validated together before the PR lands.

• A repo that could not be scanned says so. Zero findings is never presented as proof of safety.
• If your collection does not exercise the flows a change touches, a green run is reported as not covering the change.
• No pass thresholds. Any failed iteration fails the run.
• If a fix cannot be deployed for validation, its state stays "fix proposed, not validated" for as long as that is true.

APISynQ ships as an MCP server, so agents run the same workflow your team does. Four tools: