SDKs and integrations

The REST API is the product: everything the dashboard does, you can do over HTTP. Client libraries and platform integrations are being built on top of it, and this page is an honest status list so you can plan around it.

Status

Planned means designed and on the roadmap, not available yet. Until an SDK ships for your language, call the API directly: it is a small surface, and the quickstart has working examples in cURL, TypeScript and Python.

What the SDKs will provide

The SDKs are generated from the same OpenAPI description as the API reference, so they stay in step with the API. Every language will offer:

• A configurable base URL (the EU host by default), with the API key read from the DYNAMIC_DOCUMENT_API_KEY environment variable
• Automatic retries for 429, 5xx and network errors, with exponential backoff and jitter, honouring Retry-After
• Automatically generated idempotency keys for POST requests, which you can override
• Sensible timeouts, around 70 seconds for synchronous renders
• Typed errors per error code, carrying the request_id
• Pagination iterators for list endpoints
• Helpers: wait for a render to finish, download a file as bytes or a stream, verify webhook signatures, and sign signed-link URLs locally
• A User-Agent with the SDK name and version, which you can turn off

Planned runtimes are Node.js 18 and later (including Deno, Bun and edge runtimes), Python 3.9 and later, PHP 8.1 and later, Ruby 3.1 and later, Go 1.22 and later, Java 11 and later, and .NET 8.

Using the REST API today

Any HTTP client works. A few practical notes:

• Set your client's timeout above your plan's sync timeout so you receive the 202 response instead of dropping the connection.
• Send an Idempotency-Key header on every POST request and reuse it on retries.
• Implement the small retry policy described in Errors.
• For long renders, use mode: "async" plus webhooks, which includes copy-paste verification code for Node.js and Python.
• Postman, Bruno and Insomnia can import the OpenAPI description directly.

No-code platforms

Connectors for Zapier, Make, n8n and Bubble are planned, with instant triggers for render.succeeded, render.failed, batch.completed and template.published, actions for every render type and PDF tool, and dynamic fields built from each template's schema.

Until they ship, these platforms can call the API with their generic HTTP modules:

• Authenticate with the X-API-Key header, which is easier than a bearer token in some builders.
• Use the flat convenience endpoints, for example POST /v1/pdf/from-template with template_id, data and filename.
• Most platforms abort a step after 25 to 40 seconds. Keep requests inside that budget, or submit with mode: "async" and continue from a webhook.
• GET /v1/templates and GET /v1/templates/{id}/schema give you template lists and field definitions for dropdowns and mappings.

MCP server

A remote MCP server at https://mcp.dynamicdocumentapi.com/mcp is planned, so AI agents and assistants can list templates, read their schemas and generate documents. It will use OAuth 2.1 with scoped access, let you choose a workspace and region at consent, and default new connections to test mode. Planned tools cover listing templates, reading a template schema, rendering PDFs from a template, HTML or Markdown, rendering images, retrieving a render and merging PDFs.

Building your own integration

If you distribute an integration to other workspaces:

• Send the X-Dynamic-Document-Api-Source header with a short, stable identifier for your platform, and put your integration's name and version in the User-Agent. Renders are then attributable to your integration in the dashboard's render list and usage breakdown.
• Use GET /v1/account as a connection test: it returns the workspace name and plan, which makes a good connection label.
• Build input fields from GET /v1/templates/{id}/schema rather than asking users for raw JSON, and offer a raw JSON mode as a fallback.
• Send an Idempotency-Key for every render so that a retried automation step doesn't produce duplicate documents.
• Let users set the API host, rather than hard-coding one.
• Ask users for a key with the narrowest scopes your integration needs, and support test keys.

OAuth 2.0 authorisation for marketplace apps, so users don't have to paste API keys, is planned. If you are building something and need an identifier registered, write to support@dynamicdocumentapi.com.