Skip to main content
Use webhooks when a finished task should trigger backend work — persist results, update records, moderate, or fan out to other systems. Mynth POSTs a JSON payload to your endpoint when a task completes or fails. For live browser progress, use Async and polling or Browser Polling instead. You can combine both: poll for the UI and still receive webhooks for durable server-side handling. Event names, headers, and full payload shapes are listed in the Webhooks reference.

Register a dashboard webhook

Dashboard-managed webhooks are the default production path. They are reusable across tasks and signed with HMAC-SHA256.
  1. Open the webhooks dashboard.
  2. Create a webhook with your HTTPS endpoint and the events you care about.
  3. Save the signing secret when it is shown — you need it to verify deliveries.
Once enabled, matching tasks send webhooks automatically. You do not need a webhook field on each generate request.

Handle a delivery

Every delivery is an HTTP POST with Content-Type: application/json. Respond with a 2xx status as soon as you accept the payload. Treat deliveries as at-least-once: make handlers idempotent using task.id.

Completed generate task

Failed generate task

Failed tasks include event, task, request, and errors. They do not include result.
Branch on errors[0].code. Treat client-side failures as terminal; retry only when the code is transient:
See Task error codes for the full list. request is the task request as stored by Mynth (including metadata when you set it). See Use Metadata. For rate and alt payloads, see the Webhooks reference.

Verify webhook signatures

Dashboard-managed deliveries include X-Mynth-Signature. Verify it before trusting the body. Header format:
Signed message:
Use HMAC-SHA256 with your webhook secret. Always verify against the raw request body — not a parsed and re-serialized object.
Get the secret from the webhooks dashboard when you create the webhook. For Convex, use @mynthio/sdk/convex — see Convex integration.

Attach request-level custom webhooks

On image.generate only, you can add up to 5 extra endpoints per task with webhook.custom. These are useful for task-specific or temporary URLs.
Custom endpoints are not signed. Put your own verification token in the path or query string (as above), or use another shared secret your backend checks. To skip dashboard-managed webhooks for one task while still sending custom endpoints:

Choose events

Mynth delivers these concrete events: When you subscribe in the dashboard, you can also use broader filters: The X-Mynth-Event header and payload.event always use the specific event name (for example task.image.generate.completed), even if the webhook was subscribed with task.completed or all. Generation-time content rating (rating on generate) does not emit task.image.rate.*. Rating is attached to the generate result; see Use Content Rating.

Delivery retries

Mynth retries failed deliveries (non-2xx or network errors) with exponential backoff and jitter, up to 12 attempts. For dashboard-managed webhooks, consecutive failures are tracked. After 30 consecutive failed delivery attempts, Mynth disables that webhook. Fix the endpoint, then re-enable it in the dashboard. Custom request-level endpoints are not auto-disabled; retries still apply for that job.

REST example

If you already have a dashboard webhook subscribed to generate events, omit webhook and rely on that registration.

When to use webhooks vs polling

Next steps