Skip to main content
Metronome keeps webhook delivery history for the last 30 days. Review it in the app, or use the API to audit deliveries and debug failures. See Set up webhooks for how your endpoint should acknowledge and verify notifications, and webhook types for payload shapes.

​
How notifications are organized

Delivery history is organized in four layers:
  • Webhook destination. The URL Metronome sends notification delivery attempts to. In the API, this is webhook_id.
  • Notification configuration. The rule that defines when a notification is triggered, for example, “Commit balance reaches $5”. For threshold alerts, the notification ID in the API is alert_id. System notifications do not have an ID since the rule is not configurable.
  • Triggered notification. A single instance when a notification triggers, for example, Customer A’s balance reaches $5. Customer B can trigger the same notification configuration at a separate time, which will result in a separate triggered notification. The triggered notification’s id is the id field in the webhook payload Metronome sends. That ID stays the same on every delivery attempt for that firing.
  • Delivery attempt. One HTTP request to the webhook destination for that triggered notification. If the first attempt fails, Metronome retries, and each retry is another delivery attempt for the same triggered notification.

​
Review deliveries in the app

Metronome allows you to view the status of all webhook delivery attempts directly in the Metronome app. Go to Developer > Notifications > Webhooks and click into the specific webhook destination that you’d like to view all delivery attempts for. Filter by errors, customer, alert type, and more to build a deeper understanding of the system health of your Metronome webhook integration.

​
List triggered notifications

List triggered notifications by webhook returns each triggered notification Metronome attempted to send to one webhook destination, with a summary of its delivery attempts. This can be used to understand the history of all triggered notifications for a specific webhook destination. Results are ordered by first_attempted_at descending. Each row is one triggered notification sent to that destination and includes:
  • id of the triggered notification. This is the id in the webhook payload, and it stays the same across delivery attempts.
  • webhook_id, the webhook destination
  • customer_id, which can be null for notifications that are not customer-specific
  • notification_id, the notification configuration. Null for system notifications, which have no configuration.
  • notification_type, this is alert_type for threshold notifications and policy.type for system and offset notifications.
  • first_attempted_at and last_attempted_at
  • last_response_status_code, from the latest delivery attempt
  • num_attempts, the latest number of delivery attempts for this triggered notification on this destination

​
Get a triggered notification and its attempts

Programmatically analyze a specific triggered notification further and understand the history of delivery attempts for that notification by using the API endpoint to get triggered notification and delivery attempts. This returns the full payload of the notification as well as a timeline of delivery attempts to a specific webhook destination for that triggered notification.

​
Debug a failed delivery

  1. Call list triggered notifications with the webhook destination, the time window, and filters for the customer or notification type you expect.
  2. Find triggered notifications whose latest delivery attempt has a last_response_status_code outside 200–299, or whose num_attempts is greater than 1.
  3. Call get triggered notification and delivery attempts with that triggered notification’s id to read the payload and each delivery attempt’s timestamp and status code.