ck_live_…), calls Craftkit server-to-server, and gets back a shareable PDF with no embed
session and no browser involved. It is written for flows like an offline-first mobile app that
reconnects at sign-off and renders a document on the server.
One key is enough. A single project
ck_live_ key can render, read templates, poll
renders, and create share links for its project — with no per-org provisioning. See
Authentication.The end-to-end flow
1
Confirm the template (once)
Author the
charter-handover (or your) template in the dashboard and publish it. Note the
slug and read its manifest with GET /v1/templates/:slug
so your data keys bind. See Verify before you render.2
Render server-to-server
POST /v1/templates/:slug/render with your data and an Idempotency-Key header. Craftkit
validates against the manifest and enqueues the job. See
Render a template.3
Get the result
Poll
GET /v1/renders/:id until succeeded, or receive a
webhook. Return downloadUrl to your client, or mint a durable
share link.Requirement coverage
Every capability a backend integration typically asks for, and where it is answered. Available means it works against the current API today; By design means the behavior is intentional and documented; Roadmap means it is not built yet and the workaround is linked.Worked example
A complete server-to-server render, with idempotency and polling.Next
Authentication
What one
ck_live_ key can and cannot do.Render pipelines
Three pipelines, three capability sets — pick the right one.
Idempotency
Make offline-replay retries safe.
Render lifecycle
Sync, status enum, and download durability.