Freshdesk Trigger Webhook: 1000 calls an hour and Sume bulk runs

A Freshdesk automation rule can call a webhook, but it is a poor place to start paid media runs directly: Freshdesk limits webhook requests to 1000 calls an hour and retries failures on its own. The steadier design sends the rule to a small relay that groups tickets and calls Sume's POST /v1/formats/{handle}/{slug}/bulk-runs, which takes 1 to 100 items and a concurrency window of 1 to 16.

This post covers what Freshdesk's page says about the Trigger Webhook action and what each limit means when the target is a Format run that takes minutes and spends money.

What Freshdesk documents

Freshdesk's page on webhooks in automation rules lists the GET, POST, PUT, PATCH and DELETE methods, JSON, XML or XML-encoded content, a Simple option that sends ticket properties, and an Advanced option for custom requests with placeholders (read 2026-10-10). Custom headers use the form X-Sample-CustomHeader1: VALUE.

The same page says a webhook is limited to 1000 calls in an hour, that calls past the limit are buffered until the next hour, that 200 to 299 is success and 300 to 399 is a redirect, and that other codes are retried once every 30 minutes for a total of 48 calls. Account administrators get an email when a call fails.

Why a relay beats a direct call

A direct call from the rule makes Freshdesk the retry engine. A failed call is repeated every 30 minutes up to 48 times, which is a day of retries. A temporary 503 from any hop could therefore start the same run more than once unless the request carries a stable Idempotency-Key. Whether a rule can put a ticket placeholder into a custom header value is not stated on the page I read, so do not depend on it.

A relay you control fixes this. It answers Freshdesk with a 2xx immediately, derives the key from the ticket id and a version, and owns the retries to Sume. It can also hold your Sume key, so the key does not sit inside a Freshdesk rule.

Batch with a bulk queue

When a rule fires for many tickets at once, collect them for a short window and create one queue. Each item is the same body as a single run, with its own instruction, input, output_schema, spend cap and communication.webhook_url. Keep a map from item index to ticket id, because items[i].index is the position you submitted.

Know what the queue does not do. It has no webhook, so completion arrives per item or by polling GET /v1/format-run-queues/{id} with backoff. Status completed means every item is terminal, not that every item succeeded, so branch on counts.failed. A used queue Idempotency-Key returns 202 with the old queue, so mint a new key for each batch.

Close the loop on the ticket

Each child run is an ordinary Format run. When its webhook arrives, verify the signature, dedupe on request_id, branch on outcome, and post the media URL to the ticket with your own Freshdesk call. If an item failed to start, it keeps its index with run_id: null and an error, and the rest of the queue continues.

Set generation_spend_cap_usd on every item. A queue of 100 items multiplies whatever one item can spend, and the platform maximum of $500 applies per run, not per batch.