Template renders

Templates are an optional preparation layer, not a fulfillment catalog. If you already have finished 5 × 7 or 8 × 10 artwork, submit the normal print product. Use a template only when you need Batch Relay to produce prepared artwork from a published studio template. A render output then follows the ordinary fulfillment path; it is not a legacy composite product.

Availability

The staging API has its stateful template store, private dispatcher, renderer, and managed artifact registration enabled. Production availability is separate: check that environment’s live response before enabling a production automation. A render still requires a published template owned by the API account’s studio; an unknown or unpublished template fails without dispatching work.

Create a render

POST /v1/templates/{template_id}/renders requires a studio-owned API account, print_orders:write, and an Idempotency-Key. Inputs are keyed by immutable slot IDs. Every input contains exactly one of asset_id or value; the API never infers input order from a template label. Omit revision_id to use the latest published revision. The response always returns the exact immutable template.revision_id chosen for this job. Save it to repeat the same edition later; pass it explicitly when you must pin a render.

{
  "output_id": "print-8x10-portrait",
  "inputs": {
    "image_1": { "asset_id": "bra_primary" },
    "image_2": { "asset_id": "bra_buddy" },
    "text_1": { "value": "Jane Smith" }
  }
}

An asset_id is a managed private asset reference. Create or resolve one with POST /v1/assets/ingest, then reuse that ID instead of re-supplying its original URL for each render. URL ingestion copies bytes into private temporary fulfillment storage; ingesting an existing asset_id reuses its bytes without a copy. Raw R2 keys and private delivery lease URLs are never render inputs. Each returned render artifact is a managed asset_id. Once the render reaches succeeded, place that ID into the matching public print-order asset role. A double-sided output must attach both the front and back artifacts.

Poll the render and use all surfaces

Read GET /v1/renders/{render_id} with print_orders:read. artifacts is always an array: a normal print commonly returns one artwork member, while a double-sided product can return front and back atomically. Treat surface_id as the output identity and fulfillment_role as the placement contract.

{
  "render_id": "rnd_123",
  "status": "succeeded",
  "template": {
    "id": "tpl_123",
    "revision_id": "tpr_456",
    "document_hash": "sha256:..."
  },
  "output_id": "trader-card-double-sided",
  "artifacts": [
    {
      "surface_id": "front",
      "fulfillment_role": "front",
      "asset_id": "bra_front",
      "pixel_width": 825,
      "pixel_height": 1125,
      "sha256": "sha256:..."
    },
    {
      "surface_id": "back",
      "fulfillment_role": "back",
      "asset_id": "bra_back",
      "pixel_width": 825,
      "pixel_height": 1125,
      "sha256": "sha256:..."
    }
  ]
}

Retention and reprints

Managed fulfillment assets are temporary operational copies, not a permanent customer archive. See Managed assets for the 28-day unattached window, order/shipment retention calculation, reprint holds, and bounded cleanup behavior.

Start

Core Concepts

Product reference

Availability

Create a render

Poll the render and use all surfaces

Retention and reprints

​Availability

​Create a render

​Poll the render and use all surfaces

​Retention and reprints

Availability

Create a render

Poll the render and use all surfaces

Retention and reprints