canonical: https://jentic.com/apis/ironcladapp.com/ironclad-api

# Ironcladapp Ironclad API

This Ironclad API spec exposes the authentication and resource-listing primitives for Ironclad's contract lifecycle management platform. Three endpoints cover obtaining an access token via POST `/auth/token` and listing or retrieving generic resource records, all secured by an X-API-Key header. It complements Ironclad's broader workflow API and is suited to bootstrapping integrations that need an authenticated session and a catalogue of available resources.

## For AI agents

Authenticate against Ironclad with an API key, exchange it for an access token, and list or retrieve generic resource records that catalogue what the integration can act on.

## Scope

Does not handle workflow creation, approvals, or signatures - use for Ironclad authentication and resource discovery only; pair with the Ironclad Public API spec for contract operations.

## Capabilities

- Exchange an Ironclad API key for a short-lived access token via POST `/auth/token`
- List the generic resources available to an authenticated Ironclad integration
- Retrieve metadata for a specific Ironclad resource by ID
- Bootstrap an authenticated session before calling Ironclad's full workflow API
- Drive integration-side discovery of available resource records without hardcoding IDs

## Use cases

### Bootstrap Token Exchange for an Integration

Integration services exchange a static Ironclad API key for a short-lived access token by calling POST `/auth/token` at startup or when refreshing credentials. The returned token is then used by downstream calls in the broader Ironclad workflow API, reducing exposure of the underlying key to a single bootstrap step.

Example prompt: POST `/auth/token` with the X-API-Key header set and store the returned access token in memory for the lifetime of the integration session.

### Resource Discovery Before Workflow Calls

Before issuing workflow operations, integrations call GET /resources to enumerate the resources available to them, then GET `/resources/{id}` for detail on a specific entry. This is useful when an integration manages multiple Ironclad workspaces or templates and needs to validate inputs against the live catalogue.

Example prompt: Call GET /resources to fetch the catalogue, then GET `/resources/{id}` for any entry the user references and confirm it exists before launching a workflow.

### Healthcheck and Credential Validation

Operations teams use the auth and resources endpoints as a healthcheck for an Ironclad integration. A successful POST `/auth/token` followed by GET /resources confirms that credentials, network access, and permissions are intact, providing a fast signal in monitoring dashboards before any contract action runs.

Example prompt: Run POST `/auth/token` and GET /resources every five minutes from the monitoring service and alert if either returns a non-200 status.

### Agent Bootstrap via Jentic

An AI assistant orchestrating contract workflows through Ironclad can use this spec to obtain an access token and validate resource identifiers before invoking the broader workflow API through Jentic. Jentic injects the X-API-Key from the vault and parses the auth response so the agent receives a ready-to-use token.

Example prompt: Use Jentic to search for 'get an Ironclad access token', load the POST `/auth/token` operation, and execute it to obtain a token before subsequent workflow calls.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/auth/token` | Exchange an API key for an access token |
| GET | `/resources` | List available resources |
| GET | `/resources/{id}` | Retrieve metadata for a specific resource |

## Key resources

- **Auth Token** — Exchange an X-API-Key for a short-lived bearer access token
- **Resources** — List and retrieve metadata for resources available to the integration

## Why Jentic

- **Setup:** Wiring the Ironclad API by hand means sending your X-API-Key in the header to api.ironcladapp.com, running the `/auth/token` exchange, and then listing or reading resources with the returned token. Through Jentic you install once, import the Ironclad API from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** Ironclad puts the resource id in the URL path (`/resources/{id}`), so a rule can pin your agent to one resource: it can read that resource and nothing else. You choose the operations it may call, so it stays limited to authentication and discovery unless you add more.
- **Credential handling:** Your Ironclad X-API-Key is stored once, encrypted, by your own Jentic One instance and injected into the request header at execution time. It never enters the agent's prompt, logs, or context, nor does the token returned by `/auth/token.`
- **Discovery method:** Agents search Jentic by intent such as 'get an Ironclad access token', and Jentic returns the matching operation with its input schema, so bootstrap is a single search, load, and execute step without reading the docs.

## Related APIs

- **Ironclad Public API** — Full Ironclad workflow, approval, and signature surface across 41 endpoints.
- **PandaDoc API** — Document automation, e-signature, and CPQ workflows for sales-led deals.
- **Juro API** — Browser-native contract automation with templates and approvals.

## FAQ

### What authentication does this Ironclad API use?

This spec uses an X-API-Key header for authentication and exposes POST `/auth/token` to exchange the key for a short-lived access token. Through Jentic, the API key is stored in the encrypted vault and added to the request header at execution time.

### How do I get an Ironclad access token?

Send POST `/auth/token` with the X-API-Key header set. The response returns the access token to attach to subsequent calls within its expiry window.

### Can I list available resources on this Ironclad API?

Yes. GET /resources returns the resources accessible to the caller, and GET `/resources/{id}` returns the metadata for a specific resource by ID.

### What are the rate limits for the Ironclad API?

This spec does not enforce explicit per-minute rate limits; throughput is governed by your Ironclad workspace plan. Avoid tight polling loops on /resources and cache responses where possible.

### How do I bootstrap an Ironclad integration through Jentic?

Search Jentic for 'get an Ironclad access token', load the POST `/auth/token` operation, and execute it. Jentic injects the X-API-Key and returns the parsed token for the next call.

### How does this spec relate to the Ironclad Public API?

This spec covers authentication and generic resource discovery; the Ironclad Public API spec (slug ironclad) covers the full set of 41 contract workflow, approval, and signature endpoints. Most production integrations use both.

### Can I limit what my agent is allowed to do with the Ironclad API?

Yes. Because you run Jentic One yourself, your own rules decide which operations and credentials the agent may use, so you can keep it to just authentication and discovery: exchanging your X-API-Key for a token via POST `/auth/token`, listing entries with GET /resources, and reading one entry with GET `/resources/{id}.` Since Ironclad puts the resource id in the URL path, a rule can pin the agent to a single resource so it reads that record and nothing else. The agent cannot call any operation you have not allowed.