---
title: SDK and Runtime Modes
description: DSAR exposes several public surfaces depending on whether you are
  hosting the runtime, calling it, or abstracting over multiple environments.
group: reference-developer
---
> ⚠️ **Warning:** **Alpha**
> DSAR is currently in alpha. APIs, package surfaces, configuration, and documentation may change as the project evolves.

DSAR exposes several public surfaces depending on whether you are hosting the
runtime, calling it, or abstracting over multiple environments.

## Choose the Right Package

|Package|Use when|Notes|
|--|--|--|
|`@dsar/backend`|You want to host DSAR as an HTTP runtime inside your own service|Exposes `dsarInstance()` plus generated `/spec.json` and `/docs`|
|`@dsar/node-sdk`|You want typed server-side access to the DSAR HTTP API|Supports per-request headers, retries, timeouts, idempotency, and binary upload helpers|
|`@dsar/cli`|You want terminal access, scripts, or parity checks against the HTTP surface|Maps closely to backend endpoints|
|`@dsar/core`|You want one stable application-facing client contract across multiple environments|Switches behavior by mode|

## `@dsar/backend`

Use `@dsar/backend` when DSAR is part of your own application or deployment.

```ts
import { dsarInstance } from "@dsar/backend";

const runtime = dsarInstance({ basePath: "/api/v1" });
```

Related docs:

* [Backend Runtime Core](../../architecture/backend-runtime-core.md)
* [API Contract Surface](../../architecture/api-contract-surface.md)
* [Integration Guides](../../integrations/integrations)

## `@dsar/node-sdk`

Use the Node SDK from trusted server-side code:

```ts
import { createNodeSdk } from "@dsar/node-sdk";

const client = createNodeSdk({
	baseUrl: "https://api.example.com/api/v1",
	token: process.env.DSAR_API_TOKEN,
	timeoutMs: 10_000,
	retryMaxAttempts: 2,
});
```

Highlights:

* grouped namespaces such as `requests`, `subjects`, `policies`, `retention`,
  `audit`, `webhooks`, and `system`
* per-request overrides for headers and idempotency
* `unwrap()`, `expect()`, and `orElse()` helpers on results
* binary helpers for verification evidence and fulfilment artifact flows

## `@dsar/cli`

Use the CLI for operational access and parity with the HTTP contract.

Examples:

```sh
dsar status --api-url https://api.example.com/api/v1
dsar requests get req-123 --api-url https://api.example.com/api/v1
```

Related docs:

* [DSAR CLI](./cli.md)
* [API Reference](../api)

## `@dsar/core` Modes

`@dsar/core` lets application code depend on a stable interface while choosing a
runtime mode:

* `managed`: HTTP-backed client for a hosted DSAR deployment
* `self-hosted`: HTTP-backed client for your own DSAR runtime
* `custom`: supply your own handler for deterministic routing
* `offline`: use fixtures without a backend dependency

```ts
import { buildCoreClient } from "@dsar/core";

const client = buildCoreClient({
	mode: "managed",
	baseUrl: "https://api.example.com/api/v1",
	token: process.env.DSAR_API_TOKEN,
});
```

## Auth Guidance

`DSAR_API_TOKEN` and other DSAR bearer credentials are machine-access
credentials. Keep them server-side. For browser-facing subject portals or
operator dashboards, authenticate the user in the host app first and then call
DSAR from trusted backend code.

See [Auth Model](../../architecture/auth-model.md).