Developer platform

One authorization contract.
Six implementations.

Every 2AYE SDK drives the same runtime loop against the same frozen envelope, so the language you choose changes the syntax and nothing about the security model.

Authorize your first action API reference

6 languages
61 SDK checks
1 evaluation endpoint

Installnpm install @verid/agent-sdk

import {
  VeridAgentClient,
  VeridGrantVerifier,
  executeWithAuthorization
} from "@verid/agent-sdk";

const client = new VeridAgentClient({
  baseUrl: process.env.VERID_BASE_URL,
  tenantId: process.env.VERID_TENANT_ID,
  accessToken: process.env.VERID_ACCESS_TOKEN
});

const proposal = {
  intentId: signedIntentId,
  agentId: "procurement-agent",
  tool: "datadog-billing",
  action: "renew",
  amount: "13800.00",     // string: textual scale is bound
  currency: "USD",
  counterparty: "datadog"
};

const envelope = client.envelopeFor(proposal);
const decision = await client.evaluate(proposal);

if (decision.decision !== "ALLOW") {
  throw new Error(`2AYE refused: ${decision.decision}`);
}

@verid/agent-sdk · Node 20+ and browsers26 tests · verid-sdk/javascript

The loop

Five calls, identical in every language.

The SDKs share method names on purpose. A team reading a Go integration can follow a Python one without translating the security model.

01
envelopeFor
Build the closed predicate envelope for the exact action being proposed.
02
evaluate
Evaluate through the single canonical runtime endpoint. Anything but ALLOW stops here.
03
verify
The protected tool independently verifies the ES256 signature and the exact envelope.
04
consume
Redeem the short-lived grant once, at the resource, immediately before the action runs.
05
submitReceipt
Submit what actually executed so the approved and executed action can be compared.

Status

Repository readiness is not package publication.

Each SDK below is implemented and tested in this repository. Package identifiers are the target coordinates; use the repository path until a release is published.

Language	Package identifier	Repository path	Tests / checks
JavaScriptNode 20+ and browsers	`@verid/agent-sdk`	`verid-sdk/javascript`	26
Python3.11+	`verid-sdk`	`verid-sdk/python`	8
.NETnet10.0	`Verid.Sdk`	`verid-sdk/dotnet`	12
Gostandard library only	`github.com/verid-ai/verid-sdk-go`	`verid-sdk/go`	4
JavaJDK 21+	`com.verid.sdk`	`verid-sdk/java`	7
FlutterDart 3	`verid_sdk`	`verid-sdk/flutter`	4

Counts are the checks present in each SDK’s own suite. They do not include the independently maintained platform test suite.

What is in each SDK

Four parts, not a grab bag.

Agent client

envelopeFor, evaluate, consume, submitReceipt. The four calls that drive the runtime loop.

Grant verifier

Independent ES256 and exact-envelope verification, run at the protected resource rather than trusted from the caller.

Typed envelope

Closed predicate types, so an unrecognised predicate is a refusal instead of a silently ignored field.

Test suite

The refusals are tested, not only the happy path: parameter substitution, tampering, and replay each have a case.

Quality, with evidence

Every claim here is checkable in the repository.

A good SDK is usually described as lightweight, documented, customizable, secure, and easy to use. Those are easy words to write, so each one below names the thing that makes it true.

Lightweight: No third-party dependencies in any SDK. JavaScript uses standard Fetch and Web Crypto; Go and Python use their standard libraries; Java runs on the bare JDK.
Documented: Every snippet on this page uses the symbols the SDKs actually export, and each SDK carries its own README with the same loop.
Customizable: Inject your own HTTP transport or key provider. The envelope and verification rules stay fixed because they are the security model.
Secure by default: An ALLOW is not permission to execute. Production verification refuses ephemeral issuer keys rather than trusting them.
Easy to use: One install line, one client, and the same five method names in all six languages.

SDK or the raw API

You can call the API directly. You still cannot skip the checks.

The REST API is public and the envelope format is published, so nothing here is locked behind an SDK. The difference is how much of the security model you re-implement yourself.

	2AYE SDK	Raw REST API
Time to a first governed action	Minutes	You implement envelope canonicalisation first
Envelope canonicalisation	Handled by the client	Must match the frozen format byte for byte
ES256 grant verification	Included in the verifier	You implement signature and exact-action checks
Single-use redemption	Enforced by the client	Yours to remember at the protected resource
Third-party dependencies	None	None
Best for	Most integrations	A language 2AYE does not ship yet

What every SDK enforces

The same refusals, whichever language you pick.

Amounts are strings

Textual scale is part of the authorization binding, so 13800.00 and 13800 are not interchangeable.

An ALLOW is not permission

The protected tool must still verify the signature and redeem the grant. The SDKs will not skip that.

Grants are single-use

A redeemed grant cannot be replayed, and redemption happens where the action executes.

Production refuses ephemeral keys

Verification defaults to rejecting throwaway issuer keys rather than trusting them.

One authorization contract.Six implementations.