Skip to main content
Your internal billing API, a partner’s API, the SaaS tool nobody has integrated yet — if it has a description, Fused can turn it into a service your workspace can enable. If it has no description at all, Fused can read the provider’s documentation instead. Import is a two-step review: plan parses the source and diffs it against the live service, apply commits exactly what you reviewed.

Import from a spec

The format is detected automatically — OpenAPI 3, Swagger 2, Google Discovery, AsyncAPI, Postman Collection, WSDL, GraphQL SDL, or an introspectable GraphQL endpoint.
Remote sources work the same way:
Formats that carry no version of their own — Postman collections especially — need --version. Without it, planning stops with import_version_required and writes no receipt. The CLI never invents a version.

When you only have a URL

import plan expects you to know where the spec lives. import discover does not — point it at the provider and it finds a machine-readable spec if one exists, and crawls the documentation if it does not.
Discovery is a session rather than a single shot. It resolves the source, pulls out the operations, extracts a contract, and proposes optional Fused enrichment — then stops and waits for you to review. In a terminal it opens the Engine’s review page; --no-browser prints the URL and waits instead. It never applies. When the session reaches plan_ready it writes the same receipt import plan would, at .fused/.state/import.plan.json, and you commit it the same way:
Sessions outlive the command. Resume one with --session <id>; the identity and crawl limits it started with are fixed and cannot be changed on resume.
Nothing is interactive in CI. Pass --all or repeat --select 'GET:/invoices', then either repeat --accept-proposal <id> or pass --reject-enrichment. Non-interactive runs never open or wait for browser review.

Flags

import plan

import apply

import discover

--workers, --max-pages, and --max-depth request crawl limits. The Registry clamps whatever you ask for, so treat them as hints rather than guarantees. --all and --select are alternatives, as are --accept-proposal and --reject-enrichment.

Overlays beat forking

An overlay corrects or extends provider metadata without you maintaining a fork of their spec. It stays local; the Registry parses, validates, and merges it, then returns one combined review hash. The receipt binds apply to that exact source and overlay — so what you reviewed is what lands, not whatever the URL happens to return later.

Diagnostics

Planning reports structured diagnostics wherever provider metadata cannot be represented exactly. Treat the diagnostic codes as the stable contract for automation; the messages are written for people.
  • --json gives you the diagnostic objects unchanged.
  • --strict fails the plan on warnings and errors.
  • Info-level diagnostics never fail strict mode.
Import plan and apply allow 20 minutes by default. If apply times out, its outcome is unknown — the Registry may have committed before the response was lost. Do not replay the receipt. Check workspace services list -q <slug> and service show <slug> first.

Re-importing

Importing the same provider version again creates a new internal revision rather than mutating the published one. A different provider version creates that version. Your slug resolves within your own Registry account: a matching slug updates that service, an unknown slug creates it.

Enable it in your workspace

Import registers the service. Enabling it is what makes it callable.