Trigger Workflow on a List
API to trigger a workflow for every user in a list in one call, via POST /trigger/list/.
SuprSend starts one workflow run per list member, with that user as the recipient. Every run gets the same data and tenant_id. Members are read when the trigger runs: right away, or after delay / at trigger_at if you schedule it. Dynamic lists are synced before running the workflow or fetching the list of users.
202 but no workflow runs.Authorizations
Pass as Bearer <API_KEY>. Get API Key from SuprSend dashboard Developers -> API Keys section.
Body
ID of the list whose users you want to notify. Case-insensitive. The list must exist and be enabled.
"webinar-registrants"
Slug of the workflow to trigger. The workflow must exist in the workspace.
"webinar-reminder"
Variables used in the workflow and its templates, as {{key}}. The same data goes to every list member's run. Use $recipient.<property> in templates for per-user values.
Wait this long before triggering. Pass a duration string in the format XXdXXhXXmXXs (for example, 1h30m) or a number of seconds (for example, 5400). Maximum 15 days.
"1h30m"
Trigger at this date-time, in ISO 8601 format with a timezone (for example, 2026-11-05T09:30:00Z). Maximum 15 days from now. If trigger_at is in the future, it wins over delay. If it's in the past, delay applies when set; otherwise the workflow triggers right away.
"2026-11-05T09:30:00Z"
Key stored on every run started by this trigger, so a Cancel Workflow node can stop those runs. This value overrides the workflow's Trigger-node cancellation key expression. To cancel the runs through the Cancel Workflow API instead, pass this request's $idempotency_key (or the message_id from the response) as idempotency_key.
512"webinar-2026-11-05"
Unique key for this request, up to 255 characters. Another request with the same key within 24 hours is ignored, so retries don't notify the list twice.
"webinar-reminder-2026-11-05"
Response
202 - Accepted
The request is accepted as long as its format is correct. These problems are reported later, in the Requests tab under Logs on the SuprSend dashboard - a missing list, workflow or tenant, a disabled list, an invalid delay, a trigger_at that isn't ISO 8601, or a schedule more than 15 days out.