Payload map reference

Every field Sprio writes to an external system — a CRM field, a ticket property, a message variable — is defined by a source type. This page documents every source type that exists today. You won't configure these directly as JSON (your dashboard's integration settings UI wraps them), but understanding them makes it much easier to reason about what a given field will actually contain, and why.

Source type	What it does
literal / configured / static	A fixed value, the same on every call — e.g. a hardcoded Source: "AI Calling".
call	Reads a field directly off the call record — e.g. caller_mobile, assistant_name, duration.
call_via_setting	Same as call, but which call field to read is itself configurable per org, instead of hardcoded.
metadata	Reads a value from the call's free-form metadata JSON.
metadata_date	Same as metadata, but formats the value as a date.
extracted	Reads a field captured by the call's AI extraction schema — e.g. first_name, property_type, budget, lead_intent. This is how qualification/disposition fields (like "Qualified" vs "Junk") get into a push.
extracted_via_setting	Same as extracted, but the extraction field name is configurable per org — used so one integration template can serve multiple orgs with different schemas.
template	Renders a string with {placeholder} syntax against the merged call context (call fields, metadata, extracted fields, transcript). No fallback — a missing referenced value aborts the entire push, so templates are best reserved for fields that are always populated.
transcript	The call's transcript text, full or partial.
crm_dynamic_fields	A pass-through for target-system fields that aren't part of a fixed schema — used when an org's CRM has custom fields Sprio doesn't need to know about in advance.
setting	Reads a raw configured value directly from the integration's settings — not derived from the call at all.
setting_template	Like template, but the template string itself comes from settings rather than a hardcoded default — this is how Zoho Desk's client-configurable subject/description templates work.
value_map	Looks up an extracted field's value in a per-org mapping table, with a default fallback if nothing matches — e.g. mapping lead_intent to a ticket priority.
conditional	Branches between two different source definitions based on a condition (same operators as run conditions) — e.g. one value when call details were captured, a different value when they weren't.
text_suffix	Derives a value from another source by taking the text after a delimiter — e.g. reading an assistant name like "JLL Agent - Bangalore" and extracting "Bangalore". Fails safe to a default (not a guess) if the delimiter is missing.

Why this matters when scoping a new integration

Most new field requirements map onto an existing source type — a qualification field is just an extracted enum field; a follow-up date is an extracted or metadata_date field; routing a value into different CRM fields based on an outcome is value_map or conditional. Genuinely new engineering is usually needed only when the target changes — for example, writing to a CRM object Sprio has never called before (its own new API integration), not when the value logic changes.