# Cursiv — capability guide for agents

You are operating a document signing platform on behalf of a person or a
company. This page tells you what it can do, how to reach each capability
over HTTP, and the single boundary you must not cross.

Everything here is generated from the running system, so it describes this
deployment rather than the product in general.

## The one thing you cannot do

**You cannot sign.** There is no endpoint, tool, parameter or sequence of
calls that produces a signature, adopts a signature image, accepts the
electronic-record disclosure, or marks a recipient as having consented. Do
not look for one; it is not hidden, it does not exist, and its absence is the
product.

Signing happens when a human opens a signing link and acts. You may prepare
the agreement, decide who signs it, send it, chase it, report on it and file
the result. The signature itself is theirs.

Two consequences worth holding onto:

- **Never tell a user you have signed something.** You have sent it. If a
  user asks you to "just sign it for me", explain that the platform does not
  permit it and offer to send it to them instead — they can sign in seconds
  from the link.
- Audit coverage and actor types vary by operation. New preparation, review/send and library operations record the borrowed key/person authority. Do not claim every legacy API write has an envelope audit event or actorType: agent.

## Authentication

Every request carries an API key:

```
Authorization: Bearer csv_live_...
```

Keys are created by a person under Settings / API keys and carry explicit scopes:
`envelopes:read`, `envelopes:write`, `envelopes:send`, `templates:read`, `contacts:write`, `document-brands:write`, `entities:write`, `templates:write`, `library:write`, `information:write`, `filing:write`, `webhooks:write`, `webhooks:activate`, `webhooks:retry`, `delivery:retry`, `workspace:write`.
Empty legacy scopes grant only envelopes:read, envelopes:write and templates:read.
New writes, sending, administration and delivery retries require explicit grants.
Active workspace membership and operation-specific roles also apply.
A missing scope returns `403 insufficient_scope`;
read the `error.code`, do not retry.

Errors are JSON: `{ "error": { "code", "message", "details" } }`. Codes are
stable, messages are for humans. `422 validation_failed` carries a
`details` array naming the offending field — fix and retry. `409` means
the state of the thing changed under you; re-read before deciding.

## The shape of the domain

An **envelope** is one transaction: some documents, some recipients, some
fields, and the record of what happened. It moves
`draft → sent → delivered → completed`, or ends at `declined`, `voided`
or `expired`.

A **template** is an envelope saved with named roles instead of people. Using
one casts real people into those roles. This is the cheapest and most
reliable way for you to send anything — the fields are already placed and a
human has already approved the layout.

A **recipient** has a type: `signer`, `in_person_signer`, `cc`,
`certified_delivery`, `agent`, `editor`, `intermediary`, `witness`,
`notary`. Only signers sign. A `cc` gets the finished copy and never
holds anything up — this is how you send a completed agreement to somebody's
lawyer or finance team.

A **field** is a place on a page where something goes. Available types:
`approve`, `attachment`, `checkbox`, `company`, `date`, `date_signed`, `decline`, `dropdown`, `email`, `email_input`, `first_name`, `formula`, `full_name`, `initial`, `last_name`, `note`, `number`, `radio`, `signature`, `ssn`, `stamp`, `text`, `title`, `zip`.

An **imported** record is an agreement signed somewhere else and filed here
for keeping. It is sealed and logged but carries no signing audit trail,
because nobody here witnessed the signature. Do not describe one as "signed
through Cursiv".

A **document type** is optional workspace filing metadata on the agreement,
not on an individual file. Read active choices from
`GET https://cursiv.co/api/v1/document-types` and send the returned id as
`documentTypeId`. It is deliberately absent from the evidence record and
does not change the document seal.

## What you can do

### Enterprise capability contract

The state below is the same capability data returned by the JSON discovery
response. Entitlement and operational readiness are separate: being on an
Enterprise plan does not make an unconfigured provider or jurisdiction ready.

| Key | Family | State | Entitlement | Evidence | Unavailable reason |
|---|---|---|---|---|---|
| `native_document_authoring` | documents | unavailable | all | plans/README.md#enterprise-checklist-coverage | Structured editing, deterministic export, locking and version support are scheduled for Plans 005 and 007. |
| `smart_content_libraries` | content | unavailable | all | plans/README.md#enterprise-checklist-coverage | Templates, variables and conditional content are scheduled for Plan 006 after content readiness in Plan 002. |
| `web_forms` | content | unavailable | all | plans/README.md#enterprise-checklist-coverage | Independent forms and conditional field or content logic are scheduled for Plan 006. |
| `signing_and_evidence` | trust | available | all | src/lib/envelope/evidence.ts<br>src/lib/pdf/certificate.ts<br>src/lib/transparency/log.ts | — |
| `approvals_and_redlining` | workflow | unavailable | all | plans/README.md#enterprise-checklist-coverage | Internal approval rules, negotiation versions and redlining are scheduled for Plan 007. |
| `quote_builder` | commercial | unavailable | all | plans/README.md#enterprise-checklist-coverage | The product catalogue, quotes, bundles, subscriptions and CPQ rules are scheduled for Plan 008. |
| `signer_payments` | commercial | unavailable | all | plans/README.md#enterprise-checklist-coverage | One-time, instalment and recurring signer payments are scheduled for Plan 009. |
| `contract_repository` | repository | unavailable | all | plans/README.md#enterprise-checklist-coverage | Bulk import, OCR, extraction, obligations and renewals are scheduled for Plan 010. |
| `engagement_analytics` | analytics | unavailable | all | plans/README.md#enterprise-checklist-coverage | Recipient, page, link, download and content-usage analytics are scheduled for Plan 011. |
| `rooms` | analytics | unavailable | all | plans/README.md#enterprise-checklist-coverage | Rooms, action plans, files, links, tasks and engagement are scheduled for Plan 011. |
| `workflow_automation` | automation | unavailable | all | plans/README.md#enterprise-checklist-coverage | Trigger/action automation, follow-up documents and connected workflows are scheduled for Plan 012. |
| `connector_ecosystem` | automation | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | CRM, cloud-storage, design and productivity connector classes are scheduled for Plan 012. |
| `enterprise_accounts` | enterprise | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | Account hierarchy, multiple workspaces, groups, custom roles and central administration are scheduled for Plan 003. |
| `saml_sso` | enterprise | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | SAML SSO, JIT and domain enforcement are scheduled for Plan 004. |
| `scim` | enterprise | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | SCIM 2.0 provisioning is scheduled for Plan 004. |
| `regional_data_residency` | enterprise | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | Regional routing and residency controls are scheduled for Plans 002, 003 and 016. |
| `enterprise_security_administration` | enterprise | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | Central encryption, key-policy and security administration gates are scheduled for Plans 002, 003 and 016. |
| `white_labelled_delivery` | documents | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | Brand colours, logos and wording are available. Custom sending domains, addresses and email white-labelling are scheduled for Plans 005 and 014. |
| `public_api_platform` | developer | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | OAuth 2.0, broad REST CRUD, webhook administration, sandbox, limits and idempotency are scheduled for Plan 013. |
| `embedded_editing` | developer | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | Embedded editing is scheduled for Plan 013. |
| `embedded_sending` | developer | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | Embedded sending is scheduled for Plan 013. |
| `embedded_signing` | developer | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | Embedded signing is not available before Plan 013. |
| `multichannel_delivery` | trust | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | Email delivery is available. SMS and WhatsApp delivery are scheduled for Plan 014. |
| `recipient_identity_verification` | trust | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | Access codes and email OTP are available. Advanced identity and liveness verification are scheduled for Plan 014. |
| `qes` | trust | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | Qualified electronic signatures are scheduled for Plan 014. |
| `pades` | trust | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | PAdES signing is scheduled for Plan 014. |
| `notary` | trust | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | A notary recipient role is available for routing. Remote notary workflows are scheduled for Plan 014. |
| `mobile_apps` | mobile | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | Enterprise iOS and Android applications are scheduled for Plan 015. |
| `ai_authoring` | ai | unavailable | all | plans/README.md#enterprise-checklist-coverage | AI writing and structured authoring are scheduled for Plan 006. |
| `repository_intelligence` | ai | unavailable | enterprise | plans/README.md#enterprise-checklist-coverage | Repository extraction and contract intelligence are scheduled for Plan 010. |
| `agent_mcp_workflows` | ai | available | all | src/app/api/mcp/route.ts<br>src/lib/api/capabilities.ts | — |

### Read the state of things

| Task | Call |
|---|---|
| List envelopes | `GET https://cursiv.co/api/v1/envelopes` |
| Filter by status | `?status=sent,delivered` |
| Search subject or recipient | `?q=acme` |
| Include filed records | `?kind=all` (or `?kind=imported`) |
| Filter by document type | `?documentTypeId=dty_...` (or `unclassified`) |
| Active document types | `GET https://cursiv.co/api/v1/document-types` |
| One envelope, with recipients and fields | `GET https://cursiv.co/api/v1/envelopes/{id}` |
| Its documents | `GET https://cursiv.co/api/v1/envelopes/{id}/documents` |
| The full evidence record | `GET https://cursiv.co/api/v1/envelopes/{id}/evidence` |
| Templates and their roles | `GET https://cursiv.co/api/v1/templates` |
| The address book | `GET https://cursiv.co/api/v1/contacts?q=acme` (see the caveat below) |
| This workspace, and your own limits | `GET https://cursiv.co/api/v1/workspace` |

The evidence record is the machine-readable account of everything: every
audit event with its place in the hash chain, per-document digests, the exact
disclosure each signer accepted, and the transparency-log receipt. When
somebody asks "can you prove this", this is most of the answer.

**Read it carefully rather than skimming it.** Two fields sit next to each
other and mean different things: `seal.verified` says the document has not
changed since we sealed it — which we attest, using a secret only we hold —
and `transparency` is the part a stranger can check without us. If
`transparency` is null, do not report the record as independently
verifiable. Say the seal verifies and the public receipt is absent, and let
the person decide whether that is enough.

Evidence exposes `transparency.salt` with the available receipt for independent verification. A null receipt means public proof is unavailable, not that the record is independently verified.

### Prepare an agreement

`POST https://cursiv.co/api/v1/envelopes`

```json
{
  "templateId": "env_...",
  "subject": "Mutual NDA — Acme",
  "roles": [{ "roleName": "Client", "name": "Ada Lovelace", "email": "ada@acme.test" }],
  "fieldValues": { "contract_value": "24500.00" },
  "externalId": "crm-4471",
  "documentTypeId": "dty_...",
  "send": false
}
```

Create a review with `POST https://cursiv.co/api/v1/envelopes/{id}/review`. Send that exact review through `/send-reviewed` using reviewId and idempotencyKey only when instructed. Explicit envelopes:send is required. Legacy /send and send:true refuse with review_required.

- externalId prevents duplicate creation across REST/MCP. Same content replays; changed content returns `409 idempotency_conflict`; concurrent creation returns 409 creation_in_progress.
- Draft creation never sends. Validation reports problems; do not route around them.

### Chase, correct and stop

| Task | Call |
|---|---|
| Remind everyone still outstanding | `POST https://cursiv.co/api/v1/envelopes/{id}/remind` |
| Void it, with a reason | `POST https://cursiv.co/api/v1/envelopes/{id}/void` (reason required) |
| Who is holding things up | MCP tool `who_is_holding_things_up` |

Reminders are rate-limited per envelope by the platform, not by you. If a
call reports that one was sent too recently, that is the answer — do not
loop.

### A document with no template

Something arrives as a PDF and nothing is set up for it. Prefer a template if
one fits — the fields are already placed and a person approved the layout —
but when there is none:

`POST https://cursiv.co/api/v1/envelopes/from-document`

```json
{
  "subject": "Consultancy agreement — Acme",
  "fileName": "agreement.pdf",
  "fileBase64": "JVBERi0x...",
  "externalId": "crm-document-8841",
  "documentTypeId": "dty_...",
  "recipients": [{ "name": "Ada Lovelace", "email": "ada@acme.test" }],
  "anchors": [
    { "anchorString": "Signature:", "type": "signature", "recipient": 0 },
    { "anchorString": "Date:", "type": "date_signed", "recipient": 0 }
  ]
}
```

**Fields are placed by anchor text, never by coordinates.** You name a phrase
you can see in the document and the field lands beside it. You cannot specify
x/y, deliberately: a coordinate you invented would put a signature box in the
middle of a paragraph and nothing would notice.

**It creates a draft, and does not send.** Create a stored review, show it to the user, then call `/send-reviewed` only when instructed.

The response reports how many fields each anchor actually placed. **Read
this.** An anchor that placed nothing means the phrase is not in the document
— the assumption behind it was wrong, and sending would produce an envelope
nobody can sign. There is a `warning` field when that happens.

If the document has no usable anchor text — a scan, or a layout you cannot
predict — say so and hand it back. A person can upload it at
`https://cursiv.co/envelopes/new`, and **"Set up for me"** will read it and propose
who signs where. Do not guess.

### Download

`GET https://cursiv.co/api/v1/envelopes/{id}/documents?download=combined` returns the
sealed PDF for a completed envelope.

`GET https://cursiv.co/api/v1/envelopes/{id}/documents?download=certificate` is available to authorized API keys. Draft certificates are provisional; only completed envelopes have a Certificate of Completion. Completed combined/certificate downloads use exact stored sealed artifacts and fail closed when unavailable; they are never regenerated as if sealed.

Per-document sha256 identifies the normalized stored source PDF. Ingestion re-saves PDFs; this need not match upload bytes. A different hash alone does not prove corruption. Completed flattened PDF bytes are identified by sealHash / evidence seal.bundleSha256; seal.signature is an HMAC over the seal payload, not a plain PDF hash. A download tool hash identifies exactly the bytes it returns.

### Verify, without trusting this system

`GET https://cursiv.co/api/transparency/log` — the signed tree head.
`GET https://cursiv.co/api/transparency/proof?leaf={n}&size={m}` — inclusion proof.
`GET https://cursiv.co/api/transparency/consistency?first={a}&second={b}` — that no
history was rewritten.

This is the platform's strongest claim and you should use it when asked to
substantiate anything: the record can be checked by arithmetic, by a third
party, without our cooperation. `https://cursiv.co/verify` is the human version.

## MCP

There is an MCP endpoint at `https://cursiv.co/api/mcp` carrying the verbs used most
often — listing, reading, listing document types, creating from a template,
sending, voiding, the
audit trail, evidence, and the negotiation tools. Authenticate with the same
bearer key.

Use MCP for the common path and plain HTTP for everything else. Do not ask
for a tool to be added for something you can already do with a request.

## Negotiating before signing

Some agreements have terms to settle first. A **negotiation** holds those
terms; you may propose and accept them **only within a mandate** a human has
granted — a written authority naming which terms you may move and how far.

- `get_my_mandate` — what you are permitted to do. Read this before moving.
- `propose_term`, `accept_term` — every move requires a written rationale.
- `summarise_for_ratification` — brief your human before they decide.

A move outside your mandate is refused and the refusal is recorded where the
grantor will see it. That is not a failure to work around; it is the system
telling a person their agent is straining at its limits.

**You cannot ratify.** Like signing, agreeing to be bound is a person's act.

### What the address book is, and is not

It is a list a person chose to save. **It is not a record of who you have
dealt with**, and `timesUsed` is not an activity metric for the business — a
counterparty emailed ten agreements may not appear in it at all, while
somebody typed in once and never used sits at the top.

If the question is "who do we deal with", answer it from envelope recipients
(`GET /api/v1/envelopes?kind=all` and read each one), not from here. Use the
address book for what it is good at: finding the right address for a name a
person has already saved.

### Before you promise anything

`GET https://cursiv.co/api/v1/workspace` tells you which workspace you are in, whose
authority your key borrows, your scopes, and the credit balance. Sending
costs one credit in credit-billed workspaces; validation reports actual cost. Read this before telling somebody their contract is on its
way, so that "you have two credits and three to send — shall I do two, or
would you rather top up?" replaces an apology after the fact.

## What you cannot do

Stated so you neither waste attempts nor improvise around a gap. None of
these are hidden behind a flag; they do not exist.

| | |
|---|---|
| Sign, ratify, or consent for anybody | Never. This is the product. |
| Place fields at coordinates | By anchor text only — see above. |
| Alter a published template version in place | Publish a new managed template version. |
| Verify a company or signing authority automatically | Recorded details remain unverified. |
| Correct or recall a sent envelope | Not exposed. Void it and send a corrected one. |
| Bulk send from a spreadsheet | Not exposed. |
| Invite/remove members, transfer ownership or manage email brands | These remain in the application; scoped operations cover company/default settings, existing member roles and webhooks. |
| Buy credits | Never. Tell the person; do not spend their money. |

If a user asks for one of these, say plainly that you cannot and name the
person's route to it. Do not simulate it with a sequence of calls that
approximates the result — a contract assembled sideways is worse than one
that was not assembled.

## Judgement, not just capability

Things worth doing without being asked:

- **Check before you send.** `GET /envelopes?q=` for the counterparty. An
  agreement already out for signature should not be sent twice.
- **Say what is missing.** If a template needs a value you are guessing at,
  stop and ask. A wrong number in a signed contract is worse than a delay.
- **Report honestly.** "Sent, awaiting two signatures" — not "done".
- **Watch the credits.** Sending costs one credit. Self-serve bundles: Starter: 25 credits for ZAR 245.00 including 15% VAT · Business: 100 credits for ZAR 879.00 including 15% VAT · Pro: 500 credits for ZAR 3425.00 including 15% VAT · Scale: 2500 credits for ZAR 14250.00 including 15% VAT.
  These totals include VAT and are charged as shown. From 10,000 annual sends,
  contact us for volume or bulk pricing. If a send fails for want of credits,
  tell the person; do not buy any.

Things you should refuse:

- Signing, ratifying, or accepting a disclosure for anybody.
- Sending an agreement whose terms you inferred rather than were given.
- Anything on Cursiv's excluded list — an agreement for the sale of
  land, a lease over twenty years, a bill of exchange, or a will cannot be
  signed electronically in South Africa at all. See
  https://cursiv.co/guides/electronic-signatures-south-africa.

## Conversational preparation

Start with GET /api/v1/bootstrap or MCP get_account_bootstrap: represented company, current human, document/email brands, defaults, permissions, credits and missing formal information are separate. Recorded job titles and authority claims are not verified authority.

1. prepare_agreement creates an unsent draft from finished contract text, a file or a template. externalId is required; optional entityIds, approved versioned clauses and signingArrangement {id, version, bindings} select reusable records.
2. revise_draft uses expectedVersion for wording, recipient, anchor and settings corrections. Metadata and extracted wording comparisons do not describe image/layout changes; inspect the PDFs too.
3. validate_draft is read-only. It checks recipients, fields, unresolved anchors, pending required information forms, schedules and sending cost. It never changes or sends the envelope.
4. preview_agreement creates an immutable review of source PDFs, field-overlay previews, recipients/order, proposed invitations, email branding and costs. Show that review to the user.
5. Only when instructed, send_reviewed_agreement uses envelopeId, reviewId and idempotencyKey. Changed content, recipients, settings, email brand or cost rejects the review. Explicit envelopes:send is required. A retry returns the receipt without another charge or invitation claim. Provider acceptance, delivery and signing are separate states; ambiguous provider attempts require reconciliation. This path rejects scheduled, conditional and signing-group workflows. A previously sent/recalled agreement needs a new draft.

### Preparation primitives, profiles and branding

create_envelope_from_document exposes upload-and-anchor placement. create_envelope_from_contract accepts finished Markdown and a structured signature block. Automatic signing dates and required editable text anchors are supported. Per-anchor results report matches, field IDs and warnings. No raw coordinate placement, signature creation, consent or ratification is exposed.

correct_envelope_draft requires expectedVersion; get_envelope_readiness returns readyToSend, safeToLeaveUnsent, problems, warnings and scheduledSendAt without modifying anything. preview_envelope reads a watermarked field-overlay PDF. download_envelope_document returns base64 artifact bytes and their SHA-256. Both REST and MCP share these services.

get_company_profile and get_my_profile keep legal/trading company data separate from the person's name/email/job title and API key label. search_contacts, create_contact and update_contact expose phone/company details. Explicit contacts:write and an active permitted member are required; creation defaults private, sharing must be explicit, duplicate/version conflicts require reconciliation. Trading names are not confirmed registered entities.

Document printing profiles (logo, fonts, colors, margins, header/footer, company details) are separate from email brands. Select documentBrandId for contract generation. Explicit document-brands:write plus owner/admin is required to create/update profiles. documentNumber optionally prints with a profile numberingPrefix; this is an explicit reference, not an automatic sequence. convert_document supports finished Markdown and installed file converters; Word requires LibreOffice.

### Libraries and operations

Versioned legal entities, managed templates, clauses and signing arrangements support scoped creation, inspection, updates and archival. Clauses require owner/admin approval of the exact selected version. People/contacts remain separate from legal entities; recorded contacts and claims do not prove authority.

Operations reads expose reports, filing, events, delivery diagnostics, workspace settings, information requests and completed exports. Writes use operationId and specific scopes; updates require versions. Missing-information requests return an expiring form link without sending email. Submitted information remains unverified and is incorporated only by explicit draft revision. Completed export bundles contain exact stored PDFs, certificates and evidence, failing closed if a sealed artifact is missing.

Webhooks start disabled, with explicit activation/retry permissions, public HTTPS only and pinned validated destinations. Receivers deduplicate stable event IDs. Email retries are restricted to definite rejections of explicitly eligible generic messages; signing/auth/completion messages and ambiguous outcomes cannot use this retry tool. Workspace administration supports company/default settings and restricted changes to existing members; it does not invite/remove owners or manage platform administration.

A sandbox requires a separate database, local storage, EMAIL_DRIVER=outbox and disabled external integrations. Bootstrap reports delivery mode. A request flag cannot turn a production workspace into a sandbox. Legacy metadata PATCH retains optional version behavior and legacy reminder/void operations have rate/status guards rather than the reviewed-send receipt contract; use task routes for mandatory versioned preparation and reviewed sending.


### Finished contract creation example

`POST /api/v1/envelopes/from-contract` / MCP `create_envelope_from_contract`:

```json
{
  "subject": "Consultancy agreement — Example Company",
  "externalId": "crm-example-8841-contract-v1",
  "documentName": "Consultancy agreement",
  "contractMarkdown": "# Consultancy agreement\n\nExample Company appoints Ada Example to provide the services agreed in the attached schedule.\n\n```signature\nConsultant | Ada Example | In personal capacity\n```",
  "recipients": [
    {
      "name": "Ada Example",
      "email": "ada@example.test",
      "type": "signer"
    }
  ],
  "signatories": [
    {
      "role": "Consultant",
      "recipient": 0
    }
  ]
}
```

### Complete REST inventory

| Method | Route | Behavior |
| --- | --- | --- |
| PATCH | /api/v1/agreements/{envelopeId}/revise | Versioned wording, recipient, field and settings correction with comparison |
| POST | /api/v1/agreements/prepare | Prepare a checked unsent agreement with required externalId |
| GET | /api/v1/bootstrap | Company, human, branding, defaults, permissions and credits in one read |
| GET | /api/v1/capabilities | Public Markdown or ?format=json discovery |
| POST | /api/v1/clauses/{id}/approve | Owner/admin approves this exact clause version |
| POST | /api/v1/clauses/{id}/archive | Archive with expectedVersion |
| GET | /api/v1/contacts/{contactId} | Read a visible contact |
| PATCH | /api/v1/contacts/{contactId} | Update your contact with expectedVersion; contacts:write required |
| GET | /api/v1/contacts | Search visible saved contacts with ?q= |
| POST | /api/v1/contacts | Create a private contact by default; contacts:write required |
| GET | /api/v1/document-brands/{documentBrandId} | Read document printing profile and version |
| PATCH | /api/v1/document-brands/{documentBrandId} | Update printing profile with expectedVersion |
| GET | /api/v1/document-brands | List document printing profiles, separate from email brands |
| POST | /api/v1/document-brands | Create printing profile; explicit document-brands:write and owner/admin required |
| GET | /api/v1/document-types | Active workspace filing classifications |
| POST | /api/v1/documents/convert | Convert finished Markdown or supported file bytes to PDF without sending |
| POST | /api/v1/entities/{id}/archive | Archive with expectedVersion |
| GET | /api/v1/envelopes/{envelopeId}/documents | Metadata or download=combined, certificate, or document id |
| PATCH | /api/v1/envelopes/{envelopeId}/draft | Correct an unsent draft with expectedVersion; never sends |
| GET | /api/v1/envelopes/{envelopeId}/evidence | Audit, consent, seal and available transparency receipt with salt |
| GET | /api/v1/envelopes/{envelopeId}/preview | Read a draft PDF with field overlays; optional documentId |
| GET | /api/v1/envelopes/{envelopeId}/readiness | Read validation problems, warnings and version without sending |
| POST | /api/v1/envelopes/{envelopeId}/remind | Send reminders subject to rate limits |
| POST | /api/v1/envelopes/{envelopeId}/review | Freeze document previews, recipients, proposed invitations and costs |
| GET | /api/v1/envelopes/{envelopeId}/reviews/{reviewId}/documents/{documentId} | GET envelopes within the workspace; see conversational workflow schemas |
| GET | /api/v1/envelopes/{envelopeId}/revisions | Read saved revision snapshots or compare fromVersion and toVersion |
| GET | /api/v1/envelopes/{envelopeId} | Envelope, recipients, documents and fields |
| PATCH | /api/v1/envelopes/{envelopeId} | Legacy draft metadata and void; sending requires review and send-reviewed |
| DELETE | /api/v1/envelopes/{envelopeId} | Delete a draft or closed envelope when permitted |
| POST | /api/v1/envelopes/{envelopeId}/send | Deprecated: rejects with review_required; use review then send-reviewed |
| POST | /api/v1/envelopes/{envelopeId}/send-reviewed | Send exactly reviewId with idempotencyKey; explicit envelopes:send required |
| GET | /api/v1/envelopes/{envelopeId}/validate | Read draft readiness and costs without changing the agreement |
| POST | /api/v1/envelopes/{envelopeId}/void | Void with a reason |
| POST | /api/v1/envelopes/from-contract | Render finished contract text with structured signature blocks; draft only |
| POST | /api/v1/envelopes/from-document | Upload a document and place fields by anchors; draft only |
| GET | /api/v1/envelopes | Search and filter envelopes |
| POST | /api/v1/envelopes | Create from a template; send:false for review |
| GET | /api/v1/me/profile | Current human profile and recorded authority claims |
| GET | /api/v1/operations/{resource} | Read reports, filing, webhooks, deliveries, events, workspace, information-requests or export; POST actions requires scoped operationId |
| POST | /api/v1/operations/{resource} | Read reports, filing, webhooks, deliveries, events, workspace, information-requests or export; POST actions requires scoped operationId |
| POST | /api/v1/signing-arrangements/{id}/archive | Archive with expectedVersion |
| POST | /api/v1/templates/{id}/archive | Archive with expectedVersion |
| GET | /api/v1/templates/{id} | GET templates within the workspace; see conversational workflow schemas |
| PATCH | /api/v1/templates/{id} | PATCH templates within the workspace; see conversational workflow schemas |
| GET | /api/v1/templates/library | Read versioned managed templates |
| POST | /api/v1/templates | POST templates within the workspace; see conversational workflow schemas |
| GET | /api/v1/templates | Templates, roles and field keys |
| GET | /api/v1/workspace | Workspace, company profile, current user, scopes and credits |

## Where to read more

- API reference: https://cursiv.co/docs/api
- How the transparency log works: https://cursiv.co/docs/transparency
- Security, and what it does not protect against: https://cursiv.co/security
- Electronic signature law in South Africa: https://cursiv.co/guides/electronic-signatures-south-africa