JoggAI webhook events vs Sume job.completed and run webhooks

JoggAI's API docs list four webhook events, all for avatar assets: generated_image_success, generated_image_failed, generated_motion_success and generated_motion_failed. Sume sends three terminal job events, job.completed, job.failed and job.canceled, for every generation job including an avatar video, and a separate set of run events for Formats.

JoggAI facts come from its API docs and docs index, read 2026-10-03. Sume facts come from Webhooks and Format runs and results.

What does each side promise?

From the JoggAI text, the four events cover photo-avatar image generation and motion enhancement. The same text says nothing about retry counts, backoff or a maximum number of attempts, and it advises polling no faster than every 5 seconds to avoid rate limiting. The docs index also lists a webhook integration guide, which this post did not read in full, so a retry policy may live there.

Sume documents its delivery rules in one table. Each delivery has a 10-second timeout, a failed attempt is retried up to 10 attempts in total, and the spacing between job-webhook attempts is a fixed 30 seconds by default. Ten refused attempts leave a failed delivery but a job that still reached its real terminal state, which you can read from status_url.

How do you wire the Sume side?

Submit the avatar video with mode: "webhook" and a public HTTPS webhook_url. Localhost, private-network and non-HTTPS URLs are rejected. When signing is configured, Sume signs the raw body with HMAC SHA 256 over <timestamp>.<raw_body> and sends x-sume-webhook-timestamp and x-sume-webhook-signature, and the docs suggest rejecting timestamps outside a five-minute window.

Use job_id as your idempotency key. A redelivery re-POSTs the real terminal event with a fresh timestamp and signature, and it does not consume one of the automatic attempts, so a receiver that dedupes on job_id handles retries and redeliveries the same way.

• Store the event durably, answer with any 2xx, then do the work.
• Failed and canceled events carry status: "ERROR" and an error object.
• Keep a poll of status_url for the day your endpoint is down.

Do Formats use the same events?

No. A Format run sends one format.run.terminal event per run, on completed or failed and never on canceled, and the payload is the full run receipt instead of a job result. The signature scheme is the same, so one verifier covers both surfaces, but the dedupe key differs: runs dedupe on request_id. If you mix model calls and Format runs, route on the event field before you parse the payload.