Developer

SDK and Runtime Modes

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

Choose the Right Package

PackageUse whenNotes
@dsar/backendYou want to host DSAR as an HTTP runtime inside your own serviceExposes dsarInstance() plus generated /spec.json and /docs
@dsar/node-sdkYou want typed server-side access to the DSAR HTTP APISupports per-request headers, retries, timeouts, idempotency, and binary upload helpers
@dsar/cliYou want terminal access, scripts, or parity checks against the HTTP surfaceMaps closely to backend endpoints
@dsar/coreYou want one stable application-facing client contract across multiple environmentsSwitches behavior by mode

@dsar/backend

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

Related docs:

@dsar/node-sdk

Use the Node SDK from trusted server-side code:

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:

Related docs:

@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

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.