PDFMonkey

Delete one template, via DELETE /document_templates/{id}. PERMANENT, and it is the wider of this provider's two deletes: the template is what every future generation depends on, so deleting it breaks every automation pointed at that id. Documents already generated SURVIVE -- measured, a document card still listed after its template was deleted -- but nothing new can be generated from it. It answers 204 with an EMPTY body, so confirm by asking for the template again (404 afterwards, measured) or by listing templates.

Delete one document and its generated file, via DELETE /documents/{id}. PERMANENT. PDFMonkey offers no recycle bin and no undo, and the generated file goes with the record. It answers 204 with an EMPTY body, so this reply says nothing about what happened -- confirm by asking for the document again ('Get a document' answers 404 afterwards, measured) or by listing documents and checking the id is gone. Deleting a document does not touch the template it came from.

Read the PDFMonkey account this connection authenticates as, via GET /current_user. Returns the account's name, company, e-mail, plan, trial end date and its remaining document and AI-generation quota -- `current_plan`, `available_documents` and `ai_generation_quota` are the fields worth reading before a bulk generation. THE `auth_token` FIELD IS REMOVED BEFORE YOU SEE IT, and that is this integration's doing rather than PDFMonkey's: measured 2026-09-23, PDFMonkey returns the account's own secret API key verbatim in `current_user.auth_token` -- the exact string this connection authenticates with -- so the connector replaces it with a marker. Nothing here can hand back the credential. This is also the connection's health check: it is the documented test call and the probe this provider declares.

List the account's documents as summary cards, via GET /document_cards. THIS IS THE LIST-DOCUMENTS TOOL, and its path is the reason the name says so. PDFMonkey serves no `GET /documents` at all -- that path exists only for the POST that creates one -- so a listing is always `/document_cards`. A card is the summary shape: id, status, `output_type`, `filename`, `download_url`, `preview_url`, `public_share_link`, `document_template_id` and its identifier, `created_at`/`updated_at` and `failure_cause`. It does NOT carry the `payload` or the `generation_logs`; read one document with 'Get a document' for those. Paged: the reply's `meta` gives `current_page`, `next_page`, `prev_page` and `total_pages`. Every filter is optional and they compose.

Read one document's summary card, via GET /document_cards/{id}. The same shape 'List documents' returns, for a single id: status, `filename`, `download_url`, `preview_url`, `public_share_link` and the template it came from. Prefer this over 'Get a document' when all you need is whether generation finished and where the file is -- it omits the `payload`, which can be large. Use 'Get a document' when you need the payload, the metadata or the generation logs.

List the account's templates as summary cards, via GET /document_template_cards. THIS IS THE LIST-TEMPLATES TOOL. As with documents, the listing lives on the `_cards` path; `/document_templates` serves only the POST that creates one. A card carries the template's id, `identifier`, `app_id`, `edition_mode`, `output_type`, engine name and deprecation date, its folder, `is_draft` and its timestamps -- not the body, the styles or the sample data, which 'Get a document template' returns. Paged through `meta`. `q[workspace_id]` IS OPTIONAL, which corrects the research ledger: it recorded the parameter as required, and measured 2026-09-23 the bare route answers 200 with every template in the account.

Read one template in full, via GET /document_templates/{id}. Everything a template card carries, plus the parts that make it render: `body` and `body_draft`, `scss_style` and its draft, `sample_data` and its draft, `settings`, both engine ids, the `ttl` and a `preview_url`. PDFMonkey keeps a PUBLISHED and a DRAFT copy of the body, styles, sample data and engine; generation uses the published copy, so a change that only reaches `body_draft` changes no document. The `auth_token` on a template is stripped by this connector like every other field of that name -- measured, it is not an API credential (it answers 401 against `/current_user`), but nothing on this surface consumes it and a secret-shaped field is not worth returning to an agent to find out.

Read one document in full, via GET /documents/{id}. The full record rather than the card: everything a card carries, plus the `payload` the document was rendered from, its `meta`, its `xml_data` and its `generation_logs`. `download_url` is null until `status` reaches `success`, and it is a PRESIGNED link that expires (measured: one hour), so fetch it promptly rather than storing it. A document PDFMonkey has deleted, or one belonging to another account, answers 404 with a body naming the id.

List the rendering engines a template may be pinned to, via GET /pdf_engines. Each entry carries an `id`, a `name` (v2..v5), a numeric `version` and `deprecated_on`, which is null while the engine is still supported. The ids are what 'Create a document template' and 'Update a document template' take as `pdf_engine_id` and `pdf_engine_draft_id`; a template created without one gets the newest engine. NOT AT THE PATH THE RESEARCH LEDGER RECORDED: the ledger said `GET /engines`, which answers 404 with PDFMonkey's HTML error page -- identical to an invented route, and identical with a valid key, a bogus key and no key at all, so it is routing rather than permission (all measured 2026-09-23). `GET /pdf_engines` is the route that exists and is what this tool calls.

Create a template in a workspace, via POST /document_templates. `app_id` and `identifier` are both required; omitting the identifier answers 422 `{"errors":{"identifier":["can't be blank"]}}`. `app_id` is the WORKSPACE id, which is the same value `q[workspace_id]` takes on the listings and `app_id` on every document. The body is HTML with Liquid tags, and `sample_data` is a JSON STRING rather than an object. A template created without `pdf_engine_id` gets the newest engine (measured: v5) and a `ttl` of 86400 seconds. The 201 body carries the created template, including the id 'Create a document' needs.

Create a document from a template and optionally start generating it, via POST /documents. ASYNCHRONOUS. It answers 201 as soon as the document is stored, with `status` `draft` or `pending` and `download_url` still null; the file appears later. Poll 'Get a document summary card' until `status` is `success` (then `download_url` is set) or `failure` (then `failure_cause` says why). Send `status: "pending"` to start generation on creation; the default `draft` stores it without rendering, which is how you stage a document and generate it later with 'Update a document'. Use 'Generate a document and wait' instead when you want the finished file in one call. `payload` must be a JSON OBJECT, not an array. An unknown `document_template_id` answers 422 `{"errors":{"document_template_id":["The specified template does not exist."]}}` rather than 404.

Generate a document and wait for rendering to finish, via POST /documents/sync. SYNCHRONOUS: the call blocks until the file exists, then answers 200 with the finished document -- no polling. Use it when a caller needs the PDF now; use 'Create a document' when the wait is not worth holding a request open, or when you want a draft. THE REPLY IS A CARD, and the key says so: measured 2026-09-23 the body is `{"document_card": {...}}`, not `{"document": ...}` -- so read `document_card.download_url`, and read `payload`/`generation_logs` with 'Get a document' if you need them. `status` must be `pending`: a sync call is a request to render, and `draft` has nothing to wait for. `download_url` is a presigned link that expires in an hour (measured), so download rather than store it.

Change a template's content or settings, via PUT /document_templates/{id}. Send only the fields to change; the ones omitted are left alone (measured: renaming a template and setting its `ttl` left its body, styles and sample data untouched). Editing `body` changes what EVERY later generation from this template produces, and documents already generated keep the file they were rendered with. Write to the `_draft` fields to stage a change without affecting generation. Not marked destructive -- nothing is deleted -- but it is the broadest write on this surface.

Change a document's data, metadata or status, via PUT /documents/{id}. REPLACES the fields it is given: a `payload` or `meta` sent here overwrites the stored value rather than merging into it, so send the whole object. Its main use is starting generation on a stored draft -- `{"document": {"status": "pending"}}`, measured to move a draft to `success` -- which is why it is not marked destructive even though a careless `payload` can lose data: the document survives, its content does not. Regenerating replaces the previously generated file.