Everything an AI agent can do with the Ironclad API.

A reference guide for building AI agents: every method, how to authenticate, and the permissions each one needs.

Endpoints26
API versionv1
Last updated23 June 2026
Orientation

How the Ironclad API works.

The Ironclad API is how an app or AI agent works with an Ironclad account: launching a contract workflow, advancing it through approval and signature, reading the records of completed contracts, and updating their metadata. Access is granted through an OAuth 2.0 token, and each method names the scope it needs, so a token reaches only the areas and actions it was granted. Ironclad can also push an event when a workflow or contract changes, so an integration learns about activity without polling.

26Endpoints
6Capability groups
13Read
13Write
21Permissions
Authentication
Ironclad authenticates every call with a Bearer token in the Authorization header. Tokens come from OAuth 2.0: the authorization code grant for a token tied to a signed-in user, or the client credentials grant for an app acting on its own, where a request must add an x-as-user-id or x-as-user-email header to set the acting user. The older static access token still works but was deprecated in November 2024 in favour of OAuth 2.0.
Permissions
Each public-API method requires a named OAuth scope, like public.workflows.readWorkflows to list workflows, public.workflows.sendSignatureRequests to send for signature, or public.records.updateRecords to change a contract's metadata. A token carries the scopes it was granted, and a call outside them is refused. The SCIM user and group methods sit on their own scopes, like scim.users.readUsers.
Versioning
The public API is served under a single dated v1 path and does not mint new version strings for additive changes; notable changes ship through the developer release notes. Regional hosting means the base host differs by account, like na1 for North America or eu1 for Europe, so an integration reads its account's host rather than assuming one.
Data model
A workflow is the unit that moves a contract through Create, Review, Sign, and Archive, and it carries metadata defined by a workflow schema. A completed contract becomes a record in the repository, with its own metadata schema. Documents attach to workflows and records, and a state change emits an event that Ironclad can deliver by webhook.
Connect & authenticate

Connection & authentication methods.

How an app or AI agent connects to Ironclad determines what it can reach. There is a route for making calls, a route for receiving events, and a hosted server that exposes contract search to agents, and each is governed by the token behind it and the permissions that token carries.

Ways to connect

Public REST API (v1)

The public REST API serves JSON over HTTPS under the v1 path, at a regional host such as https://na1.ironcladapp.com/public/api/v1 for North America or an eu1 host for Europe. A call authenticates with a Bearer token issued by OAuth 2.0, and each method names the OAuth scope it requires. List methods page through results.

Best forConnecting an app or AI agent to Ironclad workflows and records.
Governed byThe OAuth token and the scopes it carries.
Docs ↗

Webhooks

Ironclad POSTs an event to a registered HTTPS URL when a workflow or contract changes, for event types like workflow_launched, workflow_completed, workflow_approval_status_changed, and contract_status_changed, or a wildcard for all of them. The receiver verifies the request against the webhook verification key before trusting it.

Best forReceiving Ironclad workflow and contract events at an app or AI agent.
Governed byThe verification key on the webhook and the public.webhooks scopes used to manage it.
Docs ↗

MCP server

Ironclad publishes a hosted Model Context Protocol server that exposes its Conversational Search to AI clients, letting an agent run natural-language searches over contracts using the same engine as the dashboard. It is read-only, never creates, edits, or deletes data, and returns only results the signed-in Ironclad user is authorized to access. Claude clients are the officially supported clients.

Best forLetting an AI agent search contracts in natural language through MCP.
Governed byThe signed-in Ironclad user's permissions; read-only by design.
Docs ↗
Authentication

OAuth 2.0 authorization code grant

The authorization code grant has a user sign in and consent, then issues a Bearer token tied to that user. The token acts with that user's permissions in Ironclad, on top of the OAuth scopes it was granted. This is the route for an integration acting on behalf of a specific person.

TokenBearer access token (user-tied)
Best forAn app or agent acting on behalf of a signed-in Ironclad user.
Docs ↗

OAuth 2.0 client credentials grant

The client credentials grant lets an app obtain a Bearer token on its own, with no interactive sign-in. A request made with such a token must add an x-as-user-id or x-as-user-email header to name the acting user, so the call runs with that user's permissions. This is the route for a backend service or autonomous agent.

TokenBearer access token (app, runs as a named user)
Best forA backend service or autonomous agent calling Ironclad without a user present.
Docs ↗

Legacy access token

A static access token, generated in Ironclad, sent as a Bearer token. It was deprecated in November 2024 in favour of OAuth 2.0; existing integrations keep working for now, but new integrations should use OAuth 2.0 because the legacy token is slated to be disabled.

TokenBearer static access token (deprecated)
Best forExisting integrations not yet migrated to OAuth 2.0.
Docs ↗
Endpoint reference

Every Ironclad API method.

Filter by method, access, or permission, or search any path. Select a row for version detail, rate limits, the related webhook event, and the source.

MethodEndpointWhat it doesAccessPermissionVersion

Workflows

Methods for launching and reading contract workflows and their schemas.6

Full scope: public.workflows.readWorkflows. Reads are rate-limited to 400 requests per minute per account.

Acts onworkflow
Permission (capability)workflows.readWorkflows
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit400/min (GET workflows)

Full scope: public.workflows.readWorkflows.

Acts onworkflow
Permission (capability)workflows.readWorkflows
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit400/min (GET workflows)

Full scope: public.workflows.createWorkflows. Writes are rate-limited to 40 requests per minute per account.

Acts onworkflow
Permission (capability)workflows.createWorkflows
VersionAvailable since the API’s base version
Webhook eventworkflow_launched
Rate limit40/min (POST/PATCH workflows)

Uses 'set' to add or change values and 'remove' to clear fields. Full scope: public.workflows.updateWorkflows.

Acts onworkflow
Permission (capability)workflows.updateWorkflows
VersionAvailable since the API’s base version
Webhook eventworkflow_updated
Rate limit40/min (POST/PATCH workflows)

Full scope: public.workflows.readSchemas.

Acts onworkflow_schema
Permission (capability)workflows.readSchemas
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Full scope: public.workflows.readSchemas.

Acts onworkflow_schema
Permission (capability)workflows.readSchemas
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Workflow actions

Methods that advance a workflow: approvals, pause, resume, cancel, revert, and signature.8

Full scope: public.workflows.readApprovals.

Acts onapproval
Permission (capability)workflows.readApprovals
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Full scope: public.workflows.readApprovals.

Acts onapproval_request
Permission (capability)workflows.readApprovals
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Full scope: public.workflows.updateApprovals. Approving advances the contract.

Acts onapproval
Permission (capability)workflows.updateApprovals
VersionAvailable since the API’s base version
Webhook eventworkflow_approval_status_changed
Rate limit40/min (POST/PATCH workflows)

Full scope: public.workflows.pause.

Acts onworkflow
Permission (capability)workflows.pause
VersionAvailable since the API’s base version
Webhook eventworkflow_paused
Rate limit40/min (POST/PATCH workflows)

Full scope: public.workflows.resume.

Acts onworkflow
Permission (capability)workflows.resume
VersionAvailable since the API’s base version
Webhook eventworkflow_resumed
Rate limit40/min (POST/PATCH workflows)

Full scope: public.workflows.cancel. Ends the contract process.

Acts onworkflow
Permission (capability)workflows.cancel
VersionAvailable since the API’s base version
Webhook eventworkflow_cancelled
Rate limit40/min (POST/PATCH workflows)

Full scope: public.workflows.revertToReview.

Acts onworkflow
Permission (capability)workflows.revertToReview
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit40/min (POST/PATCH workflows)

Full scope: public.workflows.sendSignatureRequests. Sends a real signature request to signers.

Acts onsignature_request
Permission (capability)workflows.sendSignature
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit40/min (POST/PATCH workflows)

Records

Methods for working with the records of completed contracts and their schema.6

Full scope: public.records.readRecords. Reads are rate-limited to 600 requests per minute per account.

Acts onrecord
Permission (capability)records.readRecords
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit600/min (GET records)

Full scope: public.records.readRecords.

Acts onrecord
Permission (capability)records.readRecords
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit600/min (GET records)

Full scope: public.records.createRecords. Writes are rate-limited to 200 requests per minute per account.

Acts onrecord
Permission (capability)records.createRecords
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit200/min (POST/PATCH records)

Full scope: public.records.updateRecords.

Acts onrecord
Permission (capability)records.updateRecords
VersionAvailable since the API’s base version
Webhook eventcontract_status_changed
Rate limit200/min (POST/PATCH records)

Full scope: public.records.readSchemas.

Acts onrecord_schema
Permission (capability)records.readSchemas
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit600/min (GET records)

Full scope: public.records.applyContractAction.

Acts onrecord
Permission (capability)records.applyAction
VersionAvailable since the API’s base version
Webhook eventcontract_status_changed
Rate limit200/min (POST/PATCH records)

Documents

Methods for downloading the documents attached to a workflow.1

Full scope: public.workflows.readDocuments. Returns the document contents.

Acts ondocument
Permission (capability)workflows.readDocuments
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Webhooks

Methods for registering, listing, and removing event subscriptions.3

Full scope: public.webhooks.createWebhooks. Webhook methods are rate-limited to 600 requests per minute per account.

Acts onwebhook
Permission (capability)webhooks.createWebhooks
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit600/min (webhooks)

Full scope: public.webhooks.readWebhooks.

Acts onwebhook
Permission (capability)webhooks.readWebhooks
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit600/min (webhooks)

Full scope: public.webhooks.deleteWebhooks. Stops event delivery to that endpoint.

Acts onwebhook
Permission (capability)webhooks.deleteWebhooks
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit600/min (webhooks)

Users (SCIM)

Methods for reading the users in an Ironclad account, provided through SCIM.2

SCIM 2.0 surface, on its own base path, not the public/api/v1 path. Scope: scim.users.readUsers.

Acts onuser
Permission (capability)scim.users.readUsers
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit600/min (SCIM users GET)

SCIM 2.0 surface, on its own base path. Scope: scim.users.readUsers.

Acts onuser
Permission (capability)scim.users.readUsers
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit600/min (SCIM users GET)
No endpoints match those filters.
Webhooks

Webhook events.

Ironclad can notify an app when something happens to a workflow or a contract, like a workflow launching, an approval changing, a document being signed, or a contract's status changing. It POSTs an event describing what changed, so an integration learns about activity without polling.

EventWhat it signalsTriggered by
workflow_launchedFires each time a workflow is launched, the start of a contract moving through Ironclad./workflows
workflow_updatedFires each time a workflow has been updated, including changes to its metadata./workflows/{id}/attributes
workflow_completedFires once a workflow has been completed and the contract reaches the end of its process./workflows
workflow_cancelledFires any time a workflow is cancelled./workflows/{id}/cancel
workflow_pausedFires when a workflow is paused./workflows/{id}/pause
workflow_resumedFires when a paused workflow is resumed./workflows/{id}/resume
workflow_approval_status_changedFires when an approver approves a workflow or an approval status otherwise changes./workflows/{id}/approvals/{roleId}
contract_status_changedFires when a contract record's status changes, like moving from active to expired./records/{id}
/records/{id}/actions
No events match that search.
Rate limits & pagination

Rate limits, pagination & request size.

Ironclad limits how fast an app can call, by a per-minute request rate set per account that differs by resource and by whether a call reads or writes.

Request rate

Ironclad meters requests by a per-minute rate set per account, and the ceiling depends on the resource and on whether a call reads or writes. Reads of workflows allow up to 400 requests per minute while writes to workflows allow 40; reads of records allow 600 while writes allow 200; webhook methods allow 600; and all other methods default to 800. SCIM user and group methods carry their own lower write limits. Going over returns HTTP 429 Too Many Requests, and the documented guidance is to retry on a 429 with exponential backoff.

Pagination

List methods page through results rather than returning everything at once. A list call returns a page of results plus a cursor or page marker to fetch the next page, so an integration walks the full set by following the marker until no more pages remain.

Request size

Limits are expressed as a per-minute request rate per account rather than a fixed page-size cap, and the documentation does not publish a single maximum page size that applies across every list method.

Errors

Status codes & error handling.

The status codes an agent should handle, and what to do about each.

StatusCodeMeaningWhat to do
401UnauthorizedNo valid token was provided, or the token has expired.Send a valid Bearer token in the Authorization header, and refresh or reissue the OAuth token if it has expired.
403ForbiddenThe token is valid but lacks the OAuth scope the method requires, or the acting user is not permitted to perform the action.Grant the method's named scope to the token, or act as a user who has the necessary permission in Ironclad.
404Not FoundThe requested workflow, record, document, or webhook does not exist, or is not visible to this token and acting user.Verify the identifier and confirm the acting user can see the object in this Ironclad account.
429Too Many RequestsThe account exceeded the per-minute rate limit for this kind of call.Back off and retry on an exponential backoff schedule, and smooth the request rate so it stays under the per-resource limit.
Versioning & freshness

Version history.

Ironclad serves a single dated version of its public API under the v1 path and ships changes through release notes rather than minting new version strings, and it moved authentication to OAuth 2.0, deprecating the older static token.

Version history

What changed, and when

Latest versionv1
v1Current version
Current public API (v1)

Ironclad serves a single dated version of its public API under the v1 path, covering workflows, records, documents, webhooks, schemas, entities, and obligations. Additive changes ship through the developer release notes rather than as new version strings. Methods name the OAuth scope they require.

What changed
  • Workflows: launch, retrieve, list, update metadata, manage approvals, pause, resume, cancel, revert to review, and send for signature.
  • Records: list, retrieve, create, update metadata, read the records schema, and run an action.
  • Webhooks and SCIM user and group provisioning are part of the same v1 surface.
2024-11-22Requires migration
OAuth 2.0 becomes the standard; static token deprecated

Ironclad moved API authentication to the OAuth 2.0 framework, with the authorization code grant and the client credentials grant. The previous static access token was deprecated, and existing legacy-token integrations keep working for now while OAuth 2.0 becomes the only supported method.

What changed
  • OAuth 2.0 authorization code grant and client credentials grant introduced.
  • Legacy static access token deprecated on 22 November 2024.
  • Client-credentials calls require an x-as-user-id or x-as-user-email header to set the acting user.

The public API is served under a single v1 path; track changes through the developer release notes.

Ironclad developer changelog ↗
Questions

Ironclad API, answered.

How does an app authenticate to the Ironclad API?+
Every request carries a Bearer token in the Authorization header. Tokens are issued through OAuth 2.0, using the authorization code grant for a user-tied token or the client credentials grant for an app acting on its own. A client-credentials request must also send an x-as-user-id or x-as-user-email header to name the acting user, so the call runs with that user's permissions.
Does an Ironclad token have granular per-endpoint permissions?+
Yes. Each public-API method names an OAuth scope, like public.workflows.cancel or public.records.readRecords, and a token only carries the scopes it was granted. A call that needs a scope the token lacks is refused. Separately, a client-credentials token acts as a named user, so it is also bounded by what that user is allowed to see and do in Ironclad.
What is the difference between a workflow and a record?+
A workflow is the live process that moves a contract through Create, Review, Sign, and Archive, with methods to launch it, update its metadata, manage approvals, and send it for signature. A record is a completed contract stored in the repository, with its own metadata that can be read and updated. The workflow methods drive contracts in flight; the record methods work with finished ones.
How does an integration receive Ironclad events?+
An integration registers a webhook for the event types it cares about, like workflow_launched, workflow_completed, workflow_approval_status_changed, or contract_status_changed, or a wildcard for all of them. Ironclad then POSTs an event to the registered URL when a matching change happens. The receiver verifies the request using the webhook verification key before trusting it.
What happens when the rate limit is exceeded?+
Ironclad returns HTTP 429 Too Many Requests once an account passes the per-minute limit for that kind of call. The documented approach is to watch for 429 responses and retry on an exponential backoff schedule, so request volume eases until calls succeed again. Limits are set per account and differ by resource and by read versus write.
Is there a first-party Ironclad MCP server for AI agents?+
Yes. Ironclad publishes a hosted Model Context Protocol server that exposes its Conversational Search to AI clients, letting an agent run natural-language searches over contracts. It is read-only and returns only results the signed-in Ironclad user is authorized to see, so it never creates, edits, or deletes data. It does not replace the REST API for launching workflows or updating records.
Related

More legal API guides for agents

What is Bollard AI?

Control what every AI agent can do in Ironclad.

Bollard AI sits between a team's AI agents and Ironclad. Grant each agent exactly the access it needs, read or write, area by area, and every call is checked and logged.

  • Set read, write, or full access per agent, never a shared Ironclad token.
  • Denied by default, so an agent reaches only what has been explicitly allowed.
  • Every call recorded in plain English: who, what, where, and the decision.
Ironclad
Contracts Agent
Read workflows ResourceOffReadFull use
Send for signature ActionOffReadFull use
Contract records ResourceOffReadFull use
Update metadata ActionOffReadFull use
Per-agent access, set in Bollard AI, not in Ironclad