Skip to main content

Managing messages

Webhook messages can be managed programmatically through the GraphQL API or interactively through the webhook management portal.

Payload retention

The payload information in a webhook message is subject to a 90-day retention. After this period, the payload information will be removed from the message. The metadata for webhook messages remains accessible, including the message ID, timestamp and webhook event type.

GraphQL queries

You can use the GraphQL API to query webhook messages and message delivery attempts.

note

Please note that webhook-related GraphQL queries implement the GraphQL Cursor Connections Specification for paging query results with some limitations, which is different to the paging model used with other parts of the EventsAir API.

Querying webhook messages

The webhookMessages query allows you to fetch webhook messages for a subscription. The query accepts an optional status argument to filter messages by status. For example:

query WebhookMessagesExample {
webhookMessages(webhookSubscriptionId: "<string>", status: FAIL) {
edges {
node {
id
status
timestamp
webhookEventTypeName
payload
}
}
pageInfo {
hasNextPage
hasPreviousPage
startCursor
endCursor
}
}
}

This query will return a list of messages for the specified subscription with a status of FAIL. You can use the details in the pageInfo object to navigate through the results.

Querying webhook message delivery attempts

The webhookMessageDeliveryAttempts query allows you to fetch delivery attempts for a webhook message. For example:

query WebhookMessageDeliveryAttemptsExample {
webhookMessageDeliveryAttempts(webhookMessageId: "<string>") {
edges {
node {
id
status
timestamp
responseMessage
responseStatusCode
triggerType
url
}
}
pageInfo {
hasNextPage
hasPreviousPage
startCursor
endCursor
}
}
}

This query will return a list of delivery attempts for the specified webhook message. You can use the details in the pageInfo object to navigate through the results.

Resending webhook messages

You can resend messages to your application if your application has had down time or if you need to replay messages for a new webhook subscription.

Resend messages for a subscription

  • Browse to the management portal

  • Navigate to the endpoint URL for your subscription

  • Click on the menu button and select Recover failed messages or Replay missing messages:

    Webhook portal interface to manage a webhook subscription

  • Select the time window for the messages you want to resend:

    Dialog showing selection time windows to select from to resend webhook messages

  • Click on Recover or Replay to resend the messages

Resend a specific message

  • Browse to the management portal

  • Navigate to the endpoint URL for your subscription

  • In the message attempts window, click on the menu button associated with a message and select Replay:

    Webhook portal interface to manage a webhook messages for a subscription

  • Select from the options to resend failed or missing messages:

    Dialog showing selection options to resend webhook messages

  • Click on Resend to resend the messages

What's the difference between "Failed messages" and "Missing messages"?

Failed messages were attempted to be delivered to your application but failed.

Missing messages were never attempted to be delivered. For example, if a new subscription is added alongside an existing subscription, webhook messages that have already been sent to the existing subscription will not have been sent to the new subscription. You might choose to replay these webhook messages so that they can be processed by the new subscription.