Skip to content

guides

Intended Documentation

Developer Integration

The developer track — submit intents, verify Authority Tokens locally, build fail-closed connectors, govern agent tool calls through the gateway, and handle every error the runtime returns.

intermediate2 min readimplemented

Developer Integration#

This is the build track. Every page here is grounded in the shipping code — the @intended-inc/sdk, @intended/verify, and @intended/connector-sdk packages — so the signatures, fields, and error codes you read are the ones the runtime actually uses.

There are three ways to put Intended in the path of an action, in increasing order of how much you control the integration:

  • Submit intents directly. Your service calls POST /intent, reads the APPROVED / ESCALATED / DENIED decision, and acts on the result. This is the most direct path and the foundation everything else builds on.
  • Build a connector. Extend BaseAdapter from @intended/connector-sdk. The base class verifies the Authority Token — signature, tenant, adapter, expiry, single-use nonce — before your action code ever runs. Validation is fail-closed and not optional.
  • Govern an agent runtime through the gateway. Point an agent's model base URL at the LLM gateway and every tool call the model emits is evaluated before it reaches your tools. No code change inside the agent.

Start here#

Make your first authorized call

API Quickstart — obtain an intended_live_ key, submit an intent, and handle the three decision outcomes with their HTTP statuses.

Verify the token at the point of execution

Verify Decision Tokens — verify the Ed25519 Authority Token locally with @intended/verify, pin the kid, and reject on the documented failure reasons.

Enforce before you act

Connector SDK — wrap any downstream system in a fail-closed adapter, or use the SDK reference to drive intents and verification from your application.

All developer pages#

Developer Integration | Intended