# SDKs and integrations > What is available today, what is planned for SDKs, the CLI, no-code platforms and the MCP server, and how to use the REST API meanwhile. 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 [#status] | Tool | Status | | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | | REST API at `https://api-eu.dynamicdocumentapi.com/v1` | Available | | OpenAPI 3.1 description at `https://api-eu.dynamicdocumentapi.com/v1/openapi.json` and the [API reference](/docs/api-reference) | Available | | TypeScript and JavaScript SDK (`@dynamic-document-api/sdk`) | Planned | | Python SDK (`dynamic-document-api`) | Planned | | PHP SDK (`dynamic-document-api/dynamic-document-api-php`) | Planned | | Ruby, Go, Java and C# SDKs | Planned, after the first three | | Command-line interface | Planned | | Zapier, Make, n8n, Bubble | Planned | | MCP server at `https://mcp.dynamicdocumentapi.com/mcp` | Planned | | Power Automate, Pipedream, Activepieces, Airtable, Google Sheets, WordPress and WooCommerce, Shopify | Planned | 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](/docs/quickstart) has working examples in cURL, TypeScript and Python. ## What the SDKs will provide [#what-the-sdks-will-provide] The SDKs are generated from the same OpenAPI description as the [API reference](/docs/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 [#using-the-rest-api-today] Any HTTP client works. A few practical notes: * Set your client's timeout above your plan's [sync timeout](/docs/renders#sync-and-async) 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](/docs/errors#handling-errors). * For long renders, use `mode: "async"` plus [webhooks](/docs/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 [#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](/docs/renders#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 [#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 [#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](mailto:support@dynamicdocumentapi.com).