A payload template is the optional JSON object stored on a schedule that becomes the request body every time that schedule fires. It is how a scheduled firing carries meaning.
It replaces the default body
A schedule with no template still sends something. The default body identifies the run with source set to scheduled, plus scheduleId, webhookId, cronExpression, and firedAt.
Setting a template replaces that body entirely — the default fields are not merged in alongside it. So a template gives the consumer your vocabulary instead of ours:
{ "job": "nightly-reconciliation", "scope": "invoices" }
The consumer branches on the field, and routing rules can match on it to send different scheduled jobs to different destinations. What it costs is firedAt, scheduleId, and cronExpression, which the default body would have carried.
It is static
The template is stored as written and sent as written. It is not evaluated per firing, so it holds no timestamp, counter, or generated value — which is why replacing the default body also removes the only dynamic field in it. If a run needs to know when it fired, read that from the delivery record rather than expecting the template to supply it.
Related terms
- Scheduled ingest
Firing a webhook on a recurring cron cadence with no external producer.
Read - Cron expression
The five-field UTC schedule string that determines when a scheduled webhook fires.
Read - Payload
The body of an HTTP request — for webhooks, almost always JSON.
Read - Attempt
One HTTP request within a delivery's retry chain.
Read