Skip to main content
An event subscription sends the events you choose to an HTTPS endpoint you own, as signed POST requests. Use it to react to a finished run or a new review task without polling the API. Event subscriptions need a plan with the Webhooks feature and the event subscription permissions.

Before you start

  • Generate a webhook signing key. Every delivery is signed with it, and without an active key deliveries fail.
  • Pick the environment in the app header. A subscription belongs to the environment selected when you create it and receives only that environment’s events, so create one in Development for testing and another in Production for live traffic.

Creating a subscription

  1. Go to Settings → Event Subscriptions
  2. Click New Event Subscription
  3. Enter the endpoint URL. It must start with https://
  4. Select the events to send (at least one)
  5. Optionally pick Workflows to limit the subscription to their events. Leave it empty to receive events from every workflow in the environment. The field shows only if your role can view workflows
  6. Optionally add a Description (up to 200 characters)
  7. Click Create Event Subscription
After you save, the list shows the URL masked to its host and path, so a token in the query string is never displayed again. To change the URL, enter a new one when you edit the subscription; leave the field empty to keep the current one. Each environment holds up to 10 subscriptions.

Sending a test event

Choose Send test event on a subscription to deliver a ping event to its endpoint right away. The result shows the status code your endpoint answered, or the error. A test event is sent once, is never retried and never counts toward automatic disabling.

Viewing deliveries

Choose View deliveries to see every delivery of the last 7 days with its state (Pending, Succeeded, Failed or Skipped) and the status code, duration and response of its 10 most recent attempts. Filter by state to find the failures. A Skipped delivery was never sent because the subscription was disabled before its next attempt, for example while it was still being retried. Replay since sends it again.

Replaying events

From the deliveries view of an active subscription you can:
  • Replay one delivery, to send that event again with its original id.
  • Replay since a date and time within the last 7 days, to send again every failed or skipped delivery since then and every event the subscription missed, oldest first.
Replay since uses the subscription’s current events and workflows, while replaying one delivery resends that event as it is. Your endpoint should already skip ids it has processed, since a replay can resend an event it received. A disabled subscription cannot be replayed; re-enable it first.

Disabled subscriptions

A subscription is disabled when its endpoint answers 410 Gone, or automatically after 20 consecutive failed attempts with no success in 72 hours. Your organization’s admins get an in-app notification and an email, and the list shows the subscription as Disabled with the reason.

Re-enabling a subscription

Fix the endpoint, then choose Re-enable. The failure count starts over, and Ingestly offers to replay from the earliest event your endpoint did not receive: the oldest failed or skipped delivery, or the moment the subscription was disabled if that is earlier (at most 7 days back). Your endpoint catches up on what it missed, including the deliveries that were still being retried when it was disabled.

Deleting a subscription

Choose Delete and confirm. The subscription stops receiving events.