Internal service
Available to the products and teams inside the workspace you control.
Where service knowledge lives
Stop rediscovering the same API every quarter.
Registry is the company's one catalog of public APIs and private services. Bring a service in once—from a spec, a live GraphQL endpoint, or nothing more than the provider's documentation—and its operations, versions, and access requirements become something every team inherits instead of works out again.
One catalog. Versions that hold still. Changes that find you.
Service visibility
Private when you need it. Shared when you choose.
Keep internal APIs inside your workspace. When a service is meant to become part of someone else's product, expose the owned service and the versions that are ready for them.
Ready for reuse
Discoverable by other Fused workspaces when you deliberately make it available.
Sharing a service changes who can use its catalog definition—not where credentials or integration traffic run.
A closer look
Turn an API into something a team can actually pick up.
Registry takes whatever description of a service exists—or none at all—and keeps everything useful about it in one place, so a developer or an agent can work with it without a scavenger hunt through docs, old branches, and whoever integrated it last time.
Bring in whatever the provider gave you
OpenAPI, Swagger, Postman, GraphQL, or a Google Discovery document—Registry works out which one it is looking at. Internal GraphQL services can be introspected directly, and when a provider never wrote a spec at all, Registry can read their documentation instead.
Review the import before it lands
Planning reports exactly where provider metadata could not be represented cleanly. Overlays correct or extend it without forking the original spec, and apply commits the exact source you reviewed—not whatever that URL happens to return today.
Guidance that is ready to use
The operations, inputs, outputs, and context a developer or an agent needs to work with a service—without opening seven browser tabs.
Access requirements that travel
How to authenticate stays attached to the service instead of living in one project's README and one engineer's memory.
Versions that hold still
Every published service shape gets a stable identity, so products evolve when you decide to—not when a provider does.
Changes that reach the right teams
When a service moves, the update stays with it and can be surfaced to the products that actually depend on it.
Shared services that stay in sync
Shared changes reach the teams relying on them.
Registry gives every shared service one dependable history. When its owner publishes an update, the Engines using that service can tell their teams what moved and where it matters.
Two signals, one service history.
Fused knows whether the source moved or the service owner deliberately published something new.
Live API docs changedFor services created from a watched documentation page.
Shared service updatedPublished from the workspace that owns it.
The change stays attached to the service.
Registry preserves one dependable record for the owner and every workspace allowed to consume the shared service.
Change ready for relevant Engines
Each team gets context, not noise.
Every Engine checks the update against what its own products use before surfacing it to that workspace.
Your workspaceWhen your own products depend on the service.
Consumer workspacesOnly where the shared service is already in use.
Make integration knowledge outlive the person who had it.
Give every team one place to find and reuse the services your products already depend on.
Request a license key