Integration guide
Get started in 5 minutes
Integration steps
Go to authentify.bz/signup and create your customer account. You'll get a sandbox API key.
In the dashboard Agents page, create an agent and configure:
When your agent needs authorization, call the single /api/v2/authorize endpoint:
The default non-finance policy requires review after scope checks. This example returns:
Check decision, not just HTTP status: allow permits your application to execute; deny stops the action; escalate holds it for review. Authentify does not execute the requested action.
A domain policy can escalate any authorization request. Resolve it through the Authorization Requests page or the generic approval endpoint:
Use approvalRequestId, not authorizationRequestId, for a vote. Votes are cast by a signed-in approver (the operator linked to their login) or through the single-use approve/reject links emailed to operators; API keys are refused, and any operatorId in the body is ignored. A non-empty signature (typed attestation) is required. Each operator votes once; approvals remain pending until quorum is met, while a rejection resolves immediately. The audit timeline records each vote and the final outcome.
Open Audit log in the dashboard to inspect request, vote, and final-outcome events. These read-only customer endpoints require a signed-in session:
Only needed if your agent acts on behalf of a specific one of your own retail customers, not just your institution generally. Create a consent session server-to-server, authenticated with your API key:
Embed the widget in your own end-user-facing app with the returned session_id (npm install @authentify2026/consent-widget), and handle the approval: <AuthentifyConsentWidget sessionId={sessionId} onApprove={(token) => saveConsentToken(token)} onDecline={() => {}} />. Once approved, include endUserId on future /api/v2/authorize calls for that customer so Authentify checks for their consent (see Step 3): omit it and this check never runs, so agents that operate purely at the institutional level can skip this step entirely.
Key concepts
API keys
Each agent has a unique API key. Keep it secret. If compromised, revoke it from the dashboard.
OAuth 2.1 (optional)
For production, exchange your key for a short-lived access token via POST /api/v1/oauth/token (client_credentials grant) instead of sending the long-lived key on every call. Fully optional -- x-api-key keeps working unchanged. Tokens can be scoped to a subset of the agent's allowed actions, or bound to a specific end user's consent. See /api-docs for the full flow.
Scope enforcement
Authentify checks each request against the agent’s allowed_actions/entity_scope inside POST /authorize itself; your application must enforce the returned decision before executing an action. Scope violations are denied before the domain escalation policy is evaluated.
Autonomous decisions vs. human approval (Hybrid Model)
V2 returns decision: allow, deny, or escalate. The Finance adapter applies configured autonomous authority and a ceiling to context.amount. Other or unconfigured domains default to human review. An amount field alone does not grant autonomy. Configure authority and reviewer quorum per agent in the dashboard.
Operators & signatures
An operator is a named person at your institution who can approve or reject pending authorization requests. Create one with POST /v1/operators (operatorId, name, email, role), then link it to the login that person signs in with under Operators & approvals so they can vote from the dashboard; they are also emailed single-use approve/reject links when a request escalates. Every approve/reject call requires a signature: a typed attestation (e.g. the operator's full name), not a cryptographic signature, captured alongside the operator's identity, IP, device fingerprint, and timestamp in the audit trail. Create at least one operator before your first monetary call, or there'll be nobody who can resolve a pending request.
UTP signals and classification evidence
Send optional top-level signals (domain, industryContext, signal1, signal2) to V2. Authentify preserves the original UTP completeness tiers, confidence scores, and utpCode format in the response and sealed audit provenance. This metadata never changes allow, deny, or escalate. Use context.<key> rules for explicit policy decisions.
Audit logs
Authorization requests, votes, and final decisions are recorded with actor and timestamp information. Audit log opens read-only evidence, and the audit explorer verifies the tamper-evident chain.
Revocation
If an agent misbehaves or you suspect compromise, revoke it from the dashboard. All future requests are denied immediately.
Consent widget (optional)
A prebuilt, embeddable React component (@authentify2026/consent-widget) that lets one of your retail customers approve or decline an agent acting on their behalf. Only relevant if your agent needs a specific end user's consent, not for agents that operate purely at the institutional level. Each grant is scoped to one (agent, end user) pair and can be revoked by that customer at any time; revoking takes effect on the very next authorize call that includes their endUserId.
Step-up verification (optional)
A consent grant can require the end user to re-authenticate through your own sign-in before it's issued: pass require_auth: true when creating the session, and set authRedirectUrl/onAuthRedirect on the widget so it redirects there first. Your backend confirms the verification server-to-server (POST /consent-sessions/{sessionId}/confirm-auth), and Authentify refuses to grant consent until that confirmation lands.
Production checklist
Troubleshooting
Getting "Invalid key" error?
Make sure you're using the agent's API key, not the customer key. Check it in the dashboard.
Scope violation detected?
The requested action or resource is outside the agent’s scope. The request is denied. Inspect the agent configuration before retrying, and only expand permissions when appropriate.
Rate limit exceeded?
Agent hit the per-minute authorization request limit. Increase in settings or optimize request frequency.
Getting decision: "escalate"?
The request needs human review. Hold execution, then use Authorization Requests in the dashboard or the single-use approve/reject links emailed to your operators. Votes come from signed-in approvers, never an API key. One approval may leave the request pending until quorum is met.
Do I need the consent widget?
Only if your agent acts on behalf of a specific one of your own retail customers. Agents that operate purely at the institutional level, without representing an individual end user, can skip Step 7 entirely.
How does a retail customer revoke their consent later?
Embed the ConsentManager component (also from @authentify2026/consent-widget) on your own account-settings page, or call GET/DELETE /api/v1/customer/consents yourself. Revocation takes effect immediately on their next authorize call.
Where are signalQuality and utpCode?
V2 returns signalQuality and overallConfidence, plus utpCode when signals.domain is supplied. The same evidence is retained in appliedScope and the audit record. No signals produces MINIMUM; a matched rule takes precedence as RULED.
Still stuck?
Email support@authentify.bz.
SDKs
TypeScript / Node.js
A typed client covering authorization, OAuth 2.1 token management, consent sessions, approval, agent creation, and audit logs.
Building a LangChain (JS/TS) agent? @authentify2026/langchain wraps it as a native tool call.
Python
A 1:1 port of the TypeScript client's method surface, plus a LangChain (Python) wrapper. It isn't on PyPI yet; during early access we share it on request, so contact us if you need it.
No official Go SDK exists yet; call the REST API directly from Go or any other language.