Asenta

Guides

Review templates

Control how a queued item is presented to the human reviewer — the render mode, the metadata fields surfaced, and per-item reviewer instructions.

A review template is the reviewer's display layout. It decides how an item's content is rendered, which of the item's metadata fields are surfaced on the review pane, and what instructions the reviewer sees. Templates are org-defined and bound to an item per item, at intake. They are distinct from output templates, which wrap the approved content that is forwarded downstream.

Binding a template at intake

Send review_template_key in the intake payload. Asenta looks the key up within your org, validates the stored config, and freezes a snapshot of it onto the item — the same way the policy snapshot is frozen. Later edits to the template in the builder do not retroactively change items already in flight.

bash
curl -X POST https://yourapp.com/api/queue \
  -H "x-checkpoint-key: cpk_live_<YOUR_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "<p>Hi Sarah, wanted to connect about Q3 hiring...</p>",
    "confidence": 0.82,
    "segment": "outbound-email",
    "review_template_key": "outbound-email-v2",
    "metadata": {
      "prospect": "Sarah Chen",
      "company":  "Acme Corp",
      "campaign": "q3-hiring"
    }
  }'

An unknown key is never an error

If review_template_key is missing, doesn't match a template in your org, or the stored config fails validation, the item simply falls back to the default layout. Intake still succeeds — a bad or unknown key never rejects the item.

What a template controls

  • Output render mode — email, doc, or plain. Chooses how the item's content is displayed to the reviewer.
  • Surfaced metadata fields — a list of { label, path } pairs. Each path is a dotted key read out of the item's metadata and shown next to the content, so a reviewer sees the context that matters (prospect, company, campaign, ...).
  • Reviewer instructions — free text shown on the review pane telling the reviewer what to check.
  • Section order — an optional ordering of the pane's sections.

The stored config looks like this:

json
{
  "output_render": "email",          // "email" | "doc" | "plain"
  "instructions":  "Check the greeting matches the prospect and the CTA is a single ask.",
  "fields": [
    { "label": "Prospect", "path": "prospect" },
    { "label": "Company",  "path": "company" },
    { "label": "Campaign", "path": "campaign" }
  ],
  "section_order": ["instructions", "fields", "content"]
}

Metadata is surfaced safely

Field paths are traversed over own-enumerable keys only. Prototype-chain segments (__proto__, constructor, prototype) and internal top-level keys (webhooks, images) are always rejected. A missing or blocked path renders a placeholder rather than an error, and every surfaced value is HTML-escaped — metadata is never injected as raw markup. Because the config is validated at both builder-save and intake, the frozen snapshot on each item is already safe to render.

Building a template

Create and edit review templates in the dashboard at Connect → Review templates (/dashboard/review-templates). The structured builder lets you pick the render mode, add metadata fields (with a live preview drawn from a real recent item), and write reviewer instructions. Each template has a stable key — that key is what you pass as review_template_key at intake.

API reference →Core concepts →