# Agent-readable index
Source: https://atlaswork.mintlify.app/agents/index-for-llms
A curated, machine-friendly map of the Atlas docs and surfaces.
A flat, link-dense map of everything an AI agent needs to integrate Atlas. Pair
it with the auto-generated [`/llms.txt`](https://docs.atlaswork.ai/llms.txt) and
[`/llms-full.txt`](https://docs.atlaswork.ai/llms-full.txt) machine indexes.
## What Atlas is
The e-signature platform where AI agents are first-class senders. One API/MCP
call runs the full signing lifecycle: store a document, detect fields and
parties, route for signature in order, return a signed PDF plus a verifiable
audit trail. Review-first: agents prepare, humans approve.
## Surfaces
| Surface | Endpoint | Protocol | Auth |
| ------------ | ------------------------------------------ | ------------ | ---------------- |
| REST API | `https://api-atlaswork.vercel.app/api/v1` | HTTP/JSON | API key (bearer) |
| MCP server | `https://api-atlaswork.vercel.app/api/mcp` | JSON-RPC 2.0 | API key (bearer) |
| OpenAPI spec | `https://docs.atlaswork.ai/openapi.json` | OpenAPI 3.0 | none |
## Start here
* [Quickstart](/quickstart) — authenticate and make a first call.
* [Core concepts](/concepts) — envelopes, participants, fields, templates.
* [Envelope lifecycle](/guides/envelope-lifecycle) — states and transitions.
## REST
* [Authentication](/guides/authentication) — API keys; one auth method per prefix.
* [Idempotency](/guides/idempotency) — safe retries on every write.
* [Webhooks](/guides/webhooks) — signed, retried lifecycle events.
* [Errors](/guides/errors) — the `{ code, message }` envelope and codes.
* [API reference](/api-reference/introduction) — generated from the live spec.
## MCP (for agents)
* [MCP overview](/mcp/overview) — why MCP, endpoint, auth.
* [MCP transport](/mcp/transport) — JSON-RPC envelope and error codes.
* [MCP tools](/mcp/tools) — the signing tool set.
## Hard rules for integrations
1. **Review-first.** A send is not final until a human approves it. Don't assume
an agent can complete a send unattended (templates excepted).
2. **Idempotent writes.** Reuse one idempotency key per logical operation; the
SDK and MCP server supply keys automatically.
3. **Branch on `code`, not `message`.** Error `code`s are stable; messages are
for humans.
4. **Verify webhook signatures** over the raw body before trusting a payload.
5. **The generated reference is canonical.** When in doubt, read the spec at
`https://docs.atlaswork.ai/openapi.json` (also served by the API at
`/api/openapi.json`).
# Building with AI agents
Source: https://atlaswork.mintlify.app/agents/overview
How agents drive Atlas, and how they read these docs.
Atlas treats AI agents as first-class senders. There are two things an agent
needs from this site: a **tool surface** to act through, and a
**machine-readable index** of the docs to ground itself in.
## Act through the MCP server
Agents run the signing lifecycle through the [MCP server](/mcp/overview) — a
JSON-RPC tool set with review-first defaults and idempotent writes. Start there:
Why MCP, the endpoint, and auth.
The signing tool set.
## Read the docs as data
These docs publish a machine-readable index so an agent can discover and ingest
the right pages without scraping HTML:
* [`/llms.txt`](https://docs.atlaswork.ai/llms.txt) — a structured index of every
page, with titles and descriptions.
* [`/llms-full.txt`](https://docs.atlaswork.ai/llms-full.txt) — the full docs
content as a single plain-text document, ready to drop into a context window.
Any docs page is also available as Markdown by appending `.md` to its URL — for
example, `https://docs.atlaswork.ai/quickstart.md`.
See the [agent-readable index](/agents/index-for-llms) for a curated entry point.
## Principles agents can rely on
* **Agents prepare, humans approve.** Sends are review-first by default; a human
clicks Send. Don't design flows that assume an agent can finalize a send
without a human gate.
* **Retries are safe.** Every write is [idempotent](/guides/idempotency); the SDK
and MCP server supply idempotency keys automatically.
* **The reference never drifts.** The [API reference](/api-reference/introduction)
is generated from the live spec, so what an agent reads matches what the API
does.
# API reference
Source: https://atlaswork.mintlify.app/api-reference/introduction
Generated straight from the OpenAPI spec — never hand-maintained.
The pages under **Endpoints** are generated from the API's OpenAPI document.
This reference is never hand-written: adding a route to the API regenerates the
spec, and these pages follow automatically.
* **Spec:** served by the API at `/api/openapi.json`, and downloadable from this
site at [`/openapi.json`](https://docs.atlaswork.ai/openapi.json)
* **Base URL:** `https://api-atlaswork.vercel.app` (endpoints are mounted under `/api`)
Once the custom domain lands, the API serves from `api.atlaswork.ai`. The generated reference is
unaffected — it always follows the spec.
## Authentication
The REST API (`/api/v1`) uses [API keys](/guides/authentication#api-keys) passed
as a bearer token:
```bash theme={null}
curl https://api-atlaswork.vercel.app/api/v1/ping \
-H "Authorization: Bearer $ATLAS_API_KEY"
```
## Conventions
* **One error envelope** — every error is `{ "code", "message" }`. See
[Errors](/guides/errors).
* **Idempotent writes** — state-changing calls accept an idempotency key. See
[Idempotency](/guides/idempotency).
* **OpenAPI is generated, never hand-written** — REST routes are defined in code;
the spec (and this reference) follow automatically.
## Try it
Every endpoint page below includes an interactive playground. Add your API key
and send a real request without leaving the docs.
# Resolve the envelope for a signer token
Source: https://atlaswork.mintlify.app/api-reference/signer/resolve-the-envelope-for-a-signer-token
/openapi.json get /api/signer/envelope
Placeholder endpoint that proves the /signer HMAC boundary. Echoes the envelope the token was minted for.
# Liveness probe
Source: https://atlaswork.mintlify.app/api-reference/system/liveness-probe
/openapi.json get /api/health
Returns ok when the api process is serving requests. Does not touch the database or require auth.
# Authenticated ping
Source: https://atlaswork.mintlify.app/api-reference/v1/authenticated-ping
/openapi.json get /api/v1/ping
Placeholder endpoint that proves the /v1 API-key boundary. Returns pong when a valid API key is supplied.
# Core concepts
Source: https://atlaswork.mintlify.app/concepts
The objects and lifecycle behind every Atlas signing flow.
A handful of concepts describe everything Atlas does. They are the same whether
you drive Atlas from the REST API, the MCP server, or the dashboard.
## Objects
The unit of work: one document (or set of documents) routed to a set of participants for
signature. An envelope moves through a defined [lifecycle](/guides/envelope-lifecycle) and
carries its own policy — delivery mode, expiration, branding, legal framework, and metadata.
A person involved in an envelope (typically a signer, optionally a viewer or approver), with a
signing order. Each participant gets a single-purpose, tokenized link — never an account.
A fillable thing on the document: signature, initials, date, text, checkbox. Detection proposes
fields and assigns each to a participant; the sender is the final authority and can edit
everything at review.
A frequently used document with a confirmed field layout and named signer roles. Repeat sends
supply only recipients and prefill values — no detection, no review friction.
An append-only, hash-chained history of everything that happened to an envelope. On completion
it backs the audit certificate — the evidentiary record companion to the signed PDF.
A registered endpoint that receives signed, retried notifications for lifecycle events and
extraction results. See [Webhooks](/guides/webhooks).
Sending consumes a credit. Balance and ledger live in the dashboard; out-of-credit senders are
blocked only at the send moment.
## The shape of a send
Whether a developer, an agent, or a human initiates it, a send follows the same
arc:
Submit the document (by URL, inline content, or upload) and the participant list. Atlas stores
the document, starts detection asynchronously, and returns the envelope immediately with a
review URL. The caller never waits on analysis.
Detection assigns fields to participants and the envelope reaches `review`. A human inspects
placement and clicks Send — the default contract. (Template sends and explicit auto-send opt-ins
skip the gate.)
A credit is consumed, the first participant is emailed their signing link, and the envelope is
`in_progress`.
Each participant fills only their own fields and submits. Atlas advances to the next participant
or completes the envelope.
Atlas stamps the final PDF, generates the certificate, notifies everyone, and fires webhooks.
Structured extraction is available on request.
Review-first is the default everywhere: **agents prepare, humans approve.** This is a product
guarantee, not a configuration default you have to remember.
# Authentication
Source: https://atlaswork.mintlify.app/guides/authentication
One auth method per surface, enforced at the boundary.
Atlas exposes one URL prefix per audience, and **each prefix has exactly one
authentication method**, enforced in middleware. A handler never decides its own
auth, and credentials never cross surfaces.
| Prefix | Audience | Auth |
| ------------------- | -------------------------------- | ------------------- |
| `/api/v1/*` | External developers (REST) | API key |
| `/api/mcp` | AI agents (JSON-RPC 2.0 / MCP) | API key |
| `/api/signer/*` | Document recipients (no account) | HMAC envelope token |
| `/api/auth/*` | The Atlas web app (sessions) | Better Auth |
| `/api/health` | Liveness probes | None |
| `/api/openapi.json` | Docs tooling | None |
## API keys
API keys authenticate the REST API (`/api/v1`) and the MCP server (`/api/mcp`).
Create and revoke them from the [dashboard](https://web-atlaswork.vercel.app);
each key is shown in full exactly once, at creation.
Pass the key as a bearer token:
```bash theme={null}
curl https://api-atlaswork.vercel.app/api/v1/ping \
-H "Authorization: Bearer $ATLAS_API_KEY"
```
The `x-api-key` header is also accepted:
```bash theme={null}
curl https://api-atlaswork.vercel.app/api/v1/ping \
-H "x-api-key: $ATLAS_API_KEY"
```
Treat API keys as secrets. They are server-side credentials — never ship them in client-side code
or commit them to source control. Each key is rate-limited and carries per-key usage visibility
(last used) in the dashboard.
## Signer tokens
Recipients sign without ever creating an account. Each signing link carries a
stateless, HMAC-signed envelope token scoped to a single envelope (and
optionally a single signer, with an expiry). A valid signature proves Atlas
minted the token.
You never construct signer tokens yourself — Atlas issues them in the emailed
links. The `/api/signer/*` surface accepts the token as a bearer token or a
`token` query parameter, and is the only surface with CORS enabled (limited to
the apex web origin).
Least-privilege links: every emailed link authorizes exactly one person to do exactly one thing on
exactly one envelope. A signer's link can never expose another participant's fields or a different
envelope.
## Errors
Authentication failures use the standard error envelope (see
[Errors](/guides/errors)):
```json theme={null}
{ "code": "unauthorized", "message": "Missing or invalid API key" }
```
# Envelope lifecycle
Source: https://atlaswork.mintlify.app/guides/envelope-lifecycle
The states an envelope moves through, and what triggers each transition.
Every envelope moves through a defined set of states. The same lifecycle applies
no matter which surface created the envelope.
## States
| State | Meaning |
| ------------- | -------------------------------------------------------------- |
| `draft` | Created; fully editable. Detection may still be running. |
| `review` | Detection complete; fields assigned. Awaiting the Send action. |
| `in_progress` | Sent; one or more participants still need to act. |
| `completed` | All participants signed. Signed PDF and certificate available. |
| `voided` | Cancelled before completion. |
| `declined` | A participant declined; the envelope is terminated. |
| `expired` | Reached its expiration before completing. |
## Transitions
Submitting a document and participants creates the envelope in `draft` and kicks off detection
asynchronously. The response returns immediately with the envelope ID and a review URL.
Detection finishes and assigns every field to a participant. Anything in `draft` or `review` is
fully editable — fields, participants, and policy.
On **Send**, a credit is consumed and the first participant is emailed their link. With
review-first (the default), a human clicks Send; with auto-send or a trusted template, Atlas
sends as soon as detection completes.
The last participant submits. Atlas stamps the final PDF, generates the audit certificate,
notifies sender and signers, and fires webhooks.
## Mid-flight actions
Available to the sender via the REST API, MCP, and dashboard equivalently:
* **Remind** — re-send the current participant's signing email (free,
rate-limited).
* **Resend / recover link** — reissue a participant's link.
* **Void** — cancel any envelope before completion. Signers who open a voided
link see a clear "this document was canceled" state.
* **Edit drafts** — `draft`/`review` envelopes are fully editable; nothing is
editable after send except voiding.
* **Scheduled send & auto-reminders** — the envelope policy can schedule a future
send, a reminder cadence, and an expiration, all handled without caller
involvement.
## After completion
* **Signed PDF** — the original with all signatures, values, and completion
stamps embedded.
* **Audit certificate** — the companion PDF documenting the evidentiary record.
* **Structured extraction** — on request, Atlas extracts the contract's
substantive terms (parties, dates, amounts, renewal, governing law) as
structured data, optionally delivered by webhook.
* **Verification** — a public surface to confirm a signed document's integrity.
Track lifecycle transitions with [webhooks](/guides/webhooks) rather than polling — every
transition above emits an event.
# Errors
Source: https://atlaswork.mintlify.app/guides/errors
One error envelope across the whole API.
Every Atlas API error — validation, auth, not-found, rate limit, or an
unexpected bug — comes back in a single, predictable shape. Clients can rely on
one envelope everywhere.
## The envelope
```json theme={null}
{
"code": "validation_error",
"message": "Validation failed"
}
```
| Field | Type | Description |
| --------- | ------ | --------------------------------------------------- |
| `code` | string | A stable, machine-readable code. Branch on this. |
| `message` | string | A human-readable description. Display, don't parse. |
Always branch on `code`, never on `message`. Messages may change for clarity; codes are part of
the contract.
## Common codes
| HTTP status | `code` | When |
| ----------- | ------------------ | -------------------------------------------- |
| 400 | `bad_request` | Malformed request. |
| 401 | `unauthorized` | Missing or invalid credentials. |
| 403 | `forbidden` | Authenticated but not allowed. |
| 404 | `not_found` | The resource doesn't exist (or isn't yours). |
| 422 | `validation_error` | The request failed schema validation. |
| 429 | `rate_limited` | Too many requests; back off and retry. |
| 500 | `internal_error` | An unexpected server error. |
Unexpected server errors return a generic `internal_error` with no internal details — the
underlying cause is logged server-side, never leaked to the client.
## The MCP surface is different
The [MCP server](/mcp/overview) speaks JSON-RPC 2.0, so its failures stay inside
the JSON-RPC error envelope at HTTP `200` rather than using the REST envelope
above. See [MCP transport](/mcp/transport) for the JSON-RPC error codes.
# Idempotency
Source: https://atlaswork.mintlify.app/guides/idempotency
Make every state-changing call safe to retry.
Signing is high-stakes: a double-send is a real-world incident. Atlas makes all
state-changing operations idempotent so that network retries are always safe — a
retried call cannot double-create or double-send.
## How it works
State-changing requests accept an idempotency key. Atlas remembers the first
request made with a given key and returns the same result for any retry that
reuses it, instead of performing the operation again.
```bash theme={null}
curl -X POST https://api-atlaswork.vercel.app/api/v1/envelopes \
-H "Authorization: Bearer $ATLAS_API_KEY" \
-H "Idempotency-Key: 8f1c2b9a-..." \
-H "Content-Type: application/json" \
-d '{ "...": "..." }'
```
Generate one key per logical operation (for example, a UUID created before the first attempt) and
reuse it across retries of that same operation. Use a fresh key for a genuinely new operation.
## The SDK supplies keys automatically
The TypeScript SDK auto-supplies an idempotency key for every write, so retries
through the SDK are safe by default — you don't have to manage keys yourself
unless you want explicit control.
## On the MCP surface
Every write an agent performs through the [MCP server](/mcp/overview) is
idempotent by default. This is deliberate: agents retry, and a retried tool call
must never double-send a contract. See the [MCP tools](/mcp/tools) reference for
per-tool behavior.
Idempotency pairs with the review-first default: even if an agent retries the "send for review"
call, the human still approves exactly one envelope.
# Webhooks
Source: https://atlaswork.mintlify.app/guides/webhooks
Signed, retried notifications for the full envelope lifecycle.
Webhooks are the preferred way to track envelopes — register an endpoint once and
Atlas pushes lifecycle events to it, instead of you polling.
## What you receive
Every transition in the [envelope lifecycle](/guides/envelope-lifecycle) emits an
event, plus extraction results when requested. Deliveries are:
* **Signed** — every delivery carries a signature so you can verify it came from
Atlas. Reject any payload that doesn't verify.
* **Retried** — failed deliveries are retried.
* **Destination-validated** — outbound destinations are validated to prevent
Atlas being used as a request proxy.
## Managing endpoints
From the [dashboard](https://web-atlaswork.vercel.app) you can:
* Register and remove endpoints.
* See delivery history per event.
* Test-fire deliveries to confirm your handler before going live.
## Verifying a delivery
Always verify the signature before trusting a payload:
Each delivery includes a signature derived from the raw request body and your endpoint's signing
secret.
Compute the expected signature over the **raw** bytes of the request body — not a re-serialized
object — using your signing secret.
Reject the delivery if the signatures don't match. Respond `2xx` only after you've durably
accepted the event.
Preview and test environments cannot email real signers or hit real customer webhooks. Don't point
a production webhook endpoint at a non-production Atlas environment.
Make your handler idempotent: treat a repeated event ID as already-processed. Combined with
retries, this guarantees at-least-once delivery never causes duplicate side effects.
# Atlas
Source: https://atlaswork.mintlify.app/index
The e-signature platform where AI agents are first-class senders.
Atlas runs the entire signing lifecycle — store a document, prepare it, route it
to one or more parties in order, and return a signed PDF with a verifiable audit
trail — behind one clean API and MCP surface. Agents prepare, humans approve.
The developer surface **is** the product. Everything you can do in the dashboard
you can do programmatically, with review-before-send, idempotent writes, and
status built in.
Send your first envelope in a few minutes.
Envelopes, participants, fields, and the lifecycle.
Generated straight from the live OpenAPI spec — always current.
The signing lifecycle as a tool set for AI agents.
## How Atlas is documented
These docs are split by audience, mirroring the product's surfaces:
* **Guides** — task-oriented walkthroughs for building on the REST API.
* **MCP server** — the JSON-RPC tool surface for AI agents. Hand-written, because
MCP is not described by OpenAPI.
* **API reference** — generated from the API's OpenAPI document
([download](https://docs.atlaswork.ai/openapi.json)). The reference is never
hand-maintained: adding a route to the API makes it appear here.
The API reference is rendered from the API's generated spec. If an endpoint looks new or changed,
that's the source of truth catching up — not a docs edit.
## The three surfaces
| Surface | Audience | Auth |
| -------------------------------- | ----------------------- | ---------------------- |
| **REST API** (`/api/v1`) | Developers | API key |
| **MCP server** (`/api/mcp`) | AI agents | API key (JSON-RPC 2.0) |
| **Signer links** (`/api/signer`) | Recipients (no account) | HMAC envelope token |
Each surface has exactly one authentication method. See
[Authentication](/guides/authentication) for details.
# MCP server
Source: https://atlaswork.mintlify.app/mcp/overview
The signing lifecycle as a tool set for AI agents.
Atlas exposes a Model Context Protocol (MCP) server so AI agents can run the
entire signing lifecycle through tool calls. This is the **defining Atlas
workflow**: a user tells their assistant "send this NDA to Alice for signature,"
and the agent handles it end to end — agents prepare, humans approve.
The MCP surface speaks **JSON-RPC 2.0**, not REST. Because JSON-RPC is not described by OpenAPI,
this surface is documented here by hand rather than in the generated [API
reference](/api-reference/introduction).
## Why MCP
The MCP server turns signing into a small, carefully designed tool set with the
properties agents need:
* **Review-first by default** — the agent prepares an envelope and returns a
review URL; a human clicks Send. (Trusted template sends may auto-send.)
* **Idempotent writes** — a retried tool call cannot double-create or
double-send. See [Idempotency](/guides/idempotency).
* **One-call sends** — provide the document and the parties in a single call.
* **Upload sessions** — when the agent's host can't transmit files, Atlas returns
a short-lived upload link; the user drops the file there and the agent
completes the session.
## Endpoint & auth
| | |
| ------------ | ----------------------------------------------- |
| **Endpoint** | `POST https://api-atlaswork.vercel.app/api/mcp` |
| **Protocol** | JSON-RPC 2.0 |
| **Auth** | API key (bearer token or `x-api-key`) |
The MCP server uses the same [API keys](/guides/authentication#api-keys) as the
REST API. The API-key boundary is enforced in middleware before any method runs.
Request and response envelopes, error codes, and a working example.
The tools available today and the full signing tool set being built out.
# MCP tools
Source: https://atlaswork.mintlify.app/mcp/tools
The methods the Atlas MCP server answers.
Tools are invoked as JSON-RPC `method`s against `POST /api/mcp`. See
[MCP transport](/mcp/transport) for the request and response envelopes.
## Available now
### `ping`
Liveness and auth check. Proves your API key is accepted and the dispatcher is
reachable. Takes no parameters.
Ignored.
**Result**
```json theme={null}
{ "pong": true }
```
**Example**
```bash theme={null}
curl -X POST https://api-atlaswork.vercel.app/api/mcp \
-H "Authorization: Bearer $ATLAS_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "jsonrpc": "2.0", "id": 1, "method": "ping", "params": {} }'
```
## The signing tool set
The full tool suite turns the [signing lifecycle](/guides/envelope-lifecycle)
into a small, deliberate set of agent tools. Each is **review-first by default**
and **idempotent** — see [Idempotency](/guides/idempotency).
These tools are being built out. The list below is the committed surface so you can design
integrations against it; call [`ping`](#ping) today to confirm connectivity and auth. Each tool's
parameters will be documented here as it lands.
| Tool | What it does |
| ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| **send contract for review** | Create an envelope from a document and parties in one call; returns a review URL for a human to approve. |
| **send from template** | Send a known-good template by mapping recipients to roles and supplying prefill values. May auto-send, since the layout is trusted. |
| **check signing status** | Report where an envelope stands ("Alice hasn't signed yet; her link was opened yesterday"). |
| **get envelope** | Fetch a single envelope's full detail. |
| **list envelopes** | Browse envelopes for the account. |
| **list templates** / **get template** | Discover and inspect available templates and their roles. |
| **remind signer** | Re-send the current participant's signing email (rate-limited). |
| **void envelope** | Cancel an envelope before completion. |
| **extract contract data** | Pull the completed contract's structured terms (parties, dates, amounts, renewal, governing law). |
### Document inputs
The **send contract for review** tool accepts a document several ways, depending
on what the agent's host supports:
* a public **URL**,
* an **attached file** passed through,
* inline **drafted text**, or
* an **upload session** — Atlas returns a short-lived upload link, the user drops
the file there, says "done," and the agent completes the session.
Review-first is the contract of the agent surface: the agent prepares, a human clicks Send.
Template-based repeat sends are the exception, because the layout is known-good and the intent is
explicit.
# MCP transport
Source: https://atlaswork.mintlify.app/mcp/transport
The JSON-RPC 2.0 envelope the MCP server speaks.
The MCP server is a JSON-RPC 2.0 dispatcher mounted at `POST /api/mcp`. All
methods are invoked through the same request envelope, and **all failures stay
inside the JSON-RPC error envelope at HTTP `200`** — they never use the REST
[error shape](/guides/errors).
## Request envelope
```json theme={null}
{
"jsonrpc": "2.0",
"id": 1,
"method": "ping",
"params": {}
}
```
| Field | Type | Required | Description |
| --------- | ------------------------ | -------- | --------------------------------------------------------------- |
| `jsonrpc` | `"2.0"` | Yes | Protocol version; must be exactly `"2.0"`. |
| `id` | string \| number \| null | No | Echoed back on the response. Omit or `null` for a notification. |
| `method` | string | Yes | The method (tool) to invoke. |
| `params` | object | No | Method parameters. |
## Success response
```json theme={null}
{
"jsonrpc": "2.0",
"id": 1,
"result": { "pong": true }
}
```
## Error response
```json theme={null}
{
"jsonrpc": "2.0",
"id": 1,
"error": { "code": -32601, "message": "Method not found" }
}
```
### Error codes
| Code | Meaning | When |
| -------- | ---------------- | ------------------------------------------ |
| `-32700` | Parse error | The body wasn't valid JSON. |
| `-32600` | Invalid Request | The body wasn't a valid JSON-RPC request. |
| `-32601` | Method not found | The `method` isn't a registered tool. |
| `-32603` | Internal error | The tool threw while handling the request. |
Authentication failures are the one exception: a missing or invalid API key is rejected by
middleware **before** the JSON-RPC dispatcher runs, so it returns a REST `401` rather than a
JSON-RPC error.
## Example
```bash theme={null}
curl -X POST https://api-atlaswork.vercel.app/api/mcp \
-H "Authorization: Bearer $ATLAS_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "jsonrpc": "2.0", "id": 1, "method": "ping", "params": {} }'
```
```json theme={null}
{ "jsonrpc": "2.0", "id": 1, "result": { "pong": true } }
```
# Quickstart
Source: https://atlaswork.mintlify.app/quickstart
Authenticate and call your first Atlas endpoint.
This guide takes you from zero to a successful authenticated request against the
Atlas API.
While the custom domain is being set up, the API is served from
`https://api-atlaswork.vercel.app`. Endpoints are mounted under `/api`.
## 1. Get an API key
API keys are created and revoked from the [dashboard](https://web-atlaswork.vercel.app).
A key is shown in full exactly once, at creation — store it somewhere safe.
A new account starts with a free credit grant, so you can create, review, and
send a real envelope before entering any payment details.
## 2. Make an authenticated request
Every `/api/v1` request carries your API key as a bearer token (the
`x-api-key` header also works). Start with the authenticated `ping` endpoint,
which proves your key is valid:
```bash cURL theme={null}
curl https://api-atlaswork.vercel.app/api/v1/ping \
-H "Authorization: Bearer $ATLAS_API_KEY"
```
```typescript TypeScript theme={null}
const res = await fetch("https://api-atlaswork.vercel.app/api/v1/ping", {
headers: { Authorization: `Bearer ${process.env.ATLAS_API_KEY}` },
});
const body = await res.json();
console.log(body); // { "pong": true }
```
```python Python theme={null}
import os, requests
res = requests.get(
"https://api-atlaswork.vercel.app/api/v1/ping",
headers={"Authorization": f"Bearer {os.environ['ATLAS_API_KEY']}"},
)
print(res.json()) # { "pong": True }
```
A valid key returns:
```json theme={null}
{ "pong": true }
```
A missing or invalid key returns `401` with the standard error envelope:
```json theme={null}
{ "code": "unauthorized", "message": "Missing or invalid API key" }
```
## 3. Explore the API
Browse the full, always-current surface in the
[API reference](/api-reference/introduction) — it's generated from the live
OpenAPI document, so it never drifts from the running API.
## Next steps
API keys, signer tokens, and the one-method-per-prefix rule.
Make retries safe on every state-changing call.
Track the envelope lifecycle without polling.
Drive signing from an AI agent.