> ## Documentation Index
> Fetch the complete documentation index at: https://usefused.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Quickstart

> Install the CLI and ship a working SDK through one guided setup.

From nothing to a typed package your application can call. Roughly ten minutes, most of it waiting on a browser tab.

<Note>
  This assumes you already have an Engine to talk to — hosted, or one you started yourself. If not, [get one running first](/docs/deploy-an-engine); every command below needs it.
</Note>

## Install

```bash theme={null}
curl -sSL https://raw.githubusercontent.com/Usefused/cli/main/install.sh | bash
fused-cli --version
```

For automated or non-interactive installs, set `ASSUME_YES=1` to skip the confirmation prompt.

## Sign in

```bash theme={null}
fused-cli login
```

This opens your Engine's sign-in page and saves a subject-scoped credential after you approve it. The credential never passes through the browser and is never printed.

```bash theme={null}
fused-cli whoami
```

<Note>
  On a headless machine, `fused-cli login --no-browser` prints the URL instead of trying to open one.
</Note>

## Choose your service's authentication

For a supported OAuth integration, [use a Managed service](/docs/workspace/use-managed-service) to connect users without registering your own provider app. Alternatively, [store your own credentials](/docs/bucket/store-credentials). Managed auth is an explicit app configuration choice; init does not automatically choose it when local credentials are missing. Use `--no-apply` while preparing the managed reference, then plan and apply the completed config.

## Build and configure an SDK

```bash theme={null}
fused-cli init support-sdk --sdk --service linear
```

`fused-cli init` searches your workspace and then the Registry, pins a concrete service version, and asks what the SDK should expose. **All operations** is highlighted by default, so press Enter to take the complete service. Open **Choose operations…** to search by operation ID, method, path, summary, or tag and build a narrower SDK. You do not need to know operation IDs before you start.

If activation is needed, the CLI shows one combined confirmation. It keeps governance intact by writing separate workspace and SDK receipts. Missing provider credentials do not block creation: in a terminal the CLI offers to store them securely and retry planning once, while skipping that optional step still publishes the app.

When the command succeeds, the SDK is applied and its package is downloaded with generated first-call guidance. It creates only the desired state you chose: the SDK config, plus a workspace config when service activation was needed.

If no suitable Registry service exists, [import the API yourself](/docs/workspace/bring-your-own-api) from a spec, a GraphQL endpoint, or the provider's documentation.

<Warning>
  The first successful initialization prints the SDK execution token **once**. Capture it now — a repeat apply will not show it again.
</Warning>

<Note>
  Automating this? Run `fused-cli init support-sdk --sdk --service linear --select-all linear --no-input`; missing credentials are reported as readiness metadata without blocking publication. You may pre-provision them with `secret set --no-input --value-stdin`, or let the first affected call return the exact safe setup command. Use an explicit `--operation` instead when the app needs a narrower surface. The command fails rather than guessing its mode, an ambiguous service, or a capability boundary. For structured plan and apply output with independent retry boundaries, use the [advanced controlled workflow](/docs/advanced/control-the-workflow).
</Note>

## Call it

Three ways in. Same Engine execution behind all of them, and the same execution token.

| Way                             | Reach for it when                                                           | What it needs                                               |
| ------------------------------- | --------------------------------------------------------------------------- | ----------------------------------------------------------- |
| `fused-cli sdk invoke`          | Checking the path works, or poking an operation by hand                     | The CLI and the token                                       |
| The typed package               | Your application calls this for real                                        | The downloaded package and the Engine's **gRPC** address    |
| `POST /v1/apps/{id}/executions` | You are not in TypeScript or Python, or you would rather not ship a package | The Engine's **HTTP** address and the version ID from apply |

<CodeGroup>
  ```bash CLI theme={null}
  export FUSED_SDK_TOKEN='...'

  fused-cli sdk invoke support-sdk@1.0.0 issueUpdate \
    --params '{"id":"ISS-42","state":"done"}'
  ```

  ```typescript Typed package theme={null}
  import { FusedSDK } from 'support-sdk';

  const sdk = new FusedSDK({
    grpcUrl: process.env.FUSED_ENGINE_GRPC_URL,
    token: process.env.FUSED_SDK_TOKEN!,
  });

  const result = await sdk.Linear.issueUpdate({ id: 'ISS-42', state: 'done' });
  if (result.ok) console.log(result.data);
  ```

  ```bash REST theme={null}
  curl -X POST "$FUSED_ENGINE_URL/v1/apps/$VERSION_ID/executions" \
    -H "Authorization: Bearer $FUSED_SDK_TOKEN" \
    -H 'Content-Type: application/json' \
    -d '{"operation":"issueUpdate","input":{"id":"ISS-42","state":"done"}}'
  ```
</CodeGroup>

A call returns `{ ok, status, data, error }` rather than the payload itself, and services sit on the client in PascalCase with operations following the provider's own grouping — so `issueUpdate` may be `sdk.Linear.issues.update`. [Using it in your app](/docs/app/use-in-your-app) covers the whole shape; your package's generated `README.md` lists the exact paths for the operations *you* selected.

Whichever one you used, the receipt is the same:

```bash theme={null}
fused-cli sdk activity support-sdk@1.0.0
```

It shows what ran, how long the provider took, and what came back.

## What you just did

```text theme={null}
workspace  →  approved a concrete service version when it was missing
bucket     →  supplied a credential your code will never see
app        →  published an immutable, typed SDK version with its own receipt
```

## Where to go next

<CardGroup cols={2}>
  <Card title="Build an SDK properly" icon="cube" href="/docs/app/build-an-sdk">
    Multiple services, operation selection, and choosing an auth scheme.
  </Card>

  <Card title="Deploy an MCP server" icon="robot" href="/docs/mcp/deploy-a-server">
    The same approved operations, shaped for an agent.
  </Card>

  <Card title="Connect user accounts" icon="user-check" href="/docs/bucket/connect-user-accounts">
    OAuth per end user, with refresh handled by the Engine.
  </Card>

  <Card title="Share access" icon="users" href="/docs/workspace/share-access">
    Give a team what it needs without giving it everything.
  </Card>
</CardGroup>

## Prefer your coding agent to drive this?

The CLI ships skills that teach Claude Code, Codex, Cursor, Windsurf, and Antigravity the exact workflows above.

```bash theme={null}
fused-cli skill list
fused-cli skill install --for claude
```

## Taking this further

You have a working SDK on a Dev license. The tiers above it are about production licensing, SSO, and support — not about unlocking features you have just been using.

When you need those, [register interest](https://usefused.com/?plan=enterprise#enterprise-interest) and we'll size it with you.