Skip to main content
Nothing in Fused can call a service until your workspace has enabled it. This page takes a service from “exists in the Registry” to “usable by your apps.” The workspace config is the allowlist: which services are enabled, at which versions. It lives at .fused/workspace.yaml and reaches the Engine through plan and apply.

​
Find it before you add it

Reuse an already-enabled service where one fits. Workspace search filters the services you can already see, so an empty result means “nothing suitable is visible to you” — not “this service is not enabled.”
workspace has matches the service name, not the slug. Use it as an exact check, not as your primary search. If nothing suitable exists yet, bring the API in yourself.

​
Add, plan, apply

1

Add the service to your config

This edits your local file. It does not activate anything. The command prints a View stripe: link to the service in the Engine UI, which is the fastest way to check you picked the right one.
2

Preview what will change

The plan reports the Engine’s required permissions and writes a receipt to .fused/.state/.
3

Activate it

Applying a workspace config activates and deactivates services for the whole workspace. The CLI warns you when the target Engine reports environment=production. Read that warning before you continue.
Starting from nothing, fused-cli workspace init creates the skeleton, and --extend adds to it without replacing what is already there.

​
Flags

​
workspace service add

​
workspace init

Creation never replaces an existing file. Extension is additive and idempotent — re-running it reports unchanged rather than duplicating a service.

​
workspace plan / workspace apply

​
Mirror the Engine’s actual state

workspace sync rewrites your local services: map from what the Engine reports as activated right now.
This is a full mirror, not a merge. A service the Engine no longer reports is removed from your local file, and an empty remote result empties the map. Sync only touches the fields it owns, so anything else you have hand-written under a service survives.

​
When permission is the blocker

Finding a service does not mean you may add it. Planning needs workspace.read and service.manage on every changed service; applying also needs workspace.update. The built-in Admin and Owner roles carry these. Builder and Viewer do not. If you are denied, keep your draft and plan, and ask an administrator for the exact missing scope rather than working around it:

Bring your own API in

No Registry service yet? Import one from a spec, a GraphQL endpoint, or the provider’s docs.