All integrations
REST API & scoped API tokens
IN + OUT — /api/v1/extractions, /api/v1/infer, /api/tokens
When a document workflow needs to run inside your own systems, a CI pipeline or an internal tool, the REST API is how Dynamite Docs becomes plumbing. Mint a scoped, read-only key and pull structured rows out of extractions via the versioned /api/v1 surface, without a browser session anywhere in the loop.
Try it free or read the API & webhooks docs.
Document data is only useful when your systems can reach it
- A clean extraction is trapped if the only way out is a human clicking Export. Every downstream system that needs the data depends on a person.
- Scripts and pipelines need a stable credential, not a session cookie, and they need one that cannot do more than read the data they asked for.
- Custom integrations constantly re-solve the same problem. How do I get one document’s rows, in a shape I can parse, on demand?
- Broad tokens that can do everything are a standing security liability in any codebase that stores them.
How the API works
01 — Create a scoped key
From the app header (Webhooks & API), mint a read-only key. Keys look like dd_live_<64 hex>. The server stores only their SHA-256 hash, and the full secret is shown exactly once. Manage (list, revoke) them from the same panel.
02 — Pull extractions from /api/v1
GET /api/v1/extractions lists your tables with pagination and filtering; GET /api/v1/extractions/:id/export?format=csv|json|xlsx returns one in the format your pipeline consumes. Send your key in the X-API-Key header.
03 — Or infer from a document
POST /api/v1/infer uploads a document and runs the same extraction engine as the app, returning the structured table in the response. It counts as one API call plus the document’s page-equivalents against the monthly processing budget; extractions persist and trigger webhooks. The interactive POST /api/extract/infer remains for session-authenticated calls.
04 — Feed it into your systems
The JSON shape drops straight into your pipeline: a procurement system ingesting invoice rows, a finance tool importing bank statement transactions. The shape is consistent, so one consumer handles every document type.
What the API exposes
The API is a read-centric surface, deliberately small and safe to embed anywhere:
- Scoped keys — read-only, hashed at rest, secret shown once
- Versioned endpoints — GET /api/v1/extractions, GET :id/export, POST /api/v1/infer
- Pagination & filters — page, limit, sort, order, doc_type
- Formats — CSV (UTF-8 BOM), JSON, XLSX
- Inference — POST /api/v1/infer (multipart upload)
- Usage metering — GET /api/v1/usage (calls vs monthly limit)
- Rate limiting — 60/min per key, 20/min inference
A realistic example
A two-call integration, start to finish:
| Call | Purpose | Returns |
|---|
| POST /api/tokens (session auth) | Create a scoped, read-only key | dd_live_<64 hex>, shown once |
| GET /api/v1/extractions/<id>/export?format=json (X-API-Key) | Pull an extraction with the key | { columns, rows, metadata, docType } |
The API is the difference between a tool and plumbing
An extraction that can only be exported by clicking a button is a report; an extraction that can be fetched by a token-authenticated GET is an integration. The API exists to move document data into the systems that already run the business, procurement and accounting, without a human re-keying anything. For a finance team ingesting vendor invoice rows into their accounting stack, or a support team pulling structured data from inbound emails into a ticket, the API is the whole integration.
Token design is where the security thinking shows. Tokens are scoped and read-only, so a token embedded in a CI pipeline or a vendor script can read extractions but cannot delete files or touch billing. The server stores only the SHA-256 hash, so even a full database dump does not yield a usable credential. The full token is displayed exactly once, at creation, and can be revoked independently. That is standard practice, and exactly what a codebase that stores tokens in config wants.
The export payload is stable and small: columns, rows, metadata, and docType. CSV ships with a UTF-8 BOM so Excel opens it without mojibake; JSON is the shape pipelines actually consume; XLSX is there for the spreadsheet-bound. Because the shape is consistent across every extraction, one consumer can handle every document type without per-document special cases. The public surface is versioned under /api/v1 so a future breaking change ships as v2 while v1 keeps running for existing callers, and the list endpoint paginates and filters in the database rather than dumping everything at once.
Every authenticated /api/v1 request is metered against the account’s monthly API-call allowance, and the gatekeeper rate-limits per key (default 60/min). The counter lives in the same usage ledger the app writes to, so the number a developer sees in GET /api/v1/usage is the number the server enforces. Revoking a key removes its hash and the very next request is rejected, which is why pasting a leaked key into a public repo is a one-click fix, not a fire drill.
Standalone inference fills the last gap. POST /api/extract/infer runs the same extraction engine without persisting a file row, which matters for scripts that only need a one-off read of a document. It shares the same rate limits and page-equivalent budget as the interactive app, so an API blast cannot quietly bypass the pricing model that gates the hosted product.
What the API does and does not
Does
- Provides key-authenticated, read-oriented access to extractions and export formats via versioned /api/v1 endpoints.
- Stores keys as SHA-256 hashes only and shows the raw secret exactly once at creation.
- Rate-limits per key and meters every call against the monthly allowance, with a usage endpoint.
- Enforces the same page caps and monthly page-equivalent budget on standalone inference as the app.
Does not
- Does not expose a full write surface. Keys are read-only by design; mutations use your session.
- Does not allow API traffic to bypass rate limits, the monthly call allowance, or the processing budget.
- Does not store your key in plaintext anywhere on the server.
Why the API belongs in the baseline
A token-authenticated export turns every extraction into a stable data source for the systems you already run, no human in the loop, no session cookie in a script.
Read-only, hashed tokens are safe to embed in pipelines and vendor tools, which is the only kind of credential you should be committing to config.
Standalone inference gives you programmatic document reads with the same caps and budget as the app, so automation cannot quietly game the pricing model.
Questions, answered
How do I create an API key?
From the app header (Webhooks & API). The key is displayed once at creation and stored as a SHA-256 hash server-side.
What can a key do?
Keys are scoped and read-only: list and export your extractions via /api/v1. Mutations and settings stay behind your session.
Can I revoke a token?
Yes. Tokens can be revoked individually, and revocation is immediate.
Does the API respect my plan limits?
Yes. Inference is rate-limited per user/IP and draws from the same monthly page-equivalent allowance as the app, so automation cannot bypass the billing model.
Document workflows it feeds
Open app, no payment details.