> ## Documentation Index
> Fetch the complete documentation index at: https://docs.batchrelay.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Template renders

> Optionally turn published template inputs into ordinary print-ready artifacts.

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.

```json theme={null}
{
  "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.

```json theme={null}
{
  "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](/managed-assets#retention-and-reprints)
for the 28-day unattached window, order/shipment retention calculation, reprint
holds, and bounded cleanup behavior.