Events & webhooks
Events allow your system to know when something occurs within Seismic. When an event such as a LiveSend summary occurs, Seismic will send an HTTPS request to your application with a payload describing the event that occurred. You can use this information to make informed decisions like triggering a secondary action.
Enabling events
To utilize webhooks, we'll first need to enable events in your app.
Toggling on the enable events will enable you to define your event request url. In order to save your event settings we need to validate the url provided. To verify the url we'll send a request with a challenge parameter called challenge in the payload, and your endpoint must respond with that challenge value int the body to verify the url.
Request URL Verification
The request URLs are verified to ensure ownership and correctness of the notification endpoint, so that Seismic doesn't send notifications on any invalid endpoint.
Verification request/response format [NEW]
The url verification request/response format have been updated to match the actual payload structure.
This is an early access enhancement. Reach out to your CSM for using the new verification format.
{
"id": "8f7d9d8b-1d5a-4f2d-9b3e-2b7f0f7a0c11",
"version": "WebhookChallengeV1",
"occurredAt": "2026-04-07T12:34:56.000Z",
"tenantId": "234b9f0d-853d-4210-b5d2-b0574e003fcc",
"tenantName": "demo",
"data": {
"challenge": "91031261-0508-41aa-bd17-53c390a96a99" // Return this challenge string in response
},
"application": "AppRegistry",
"productArea": "Integrations"
}
{
"challenge": "91031261-0508-41aa-bd17-53c390a96a99"
}
Verification request/response format [Existing]
{
"type": "verification",
"challenge": "3eZbrw1aBm2rZgRNFdxV2595E9CY3gmdALWMmHkvFXO7tYXAYM8P"
}
HTTP 200 OK
Content-type: text/plain
3eZbrw1aBm2rZgRNFdxV2595E9CY3gmdALWMmHkvFXO7tYXAYM8P
This event does not require a specific OAuth scope or subscription. You'll automatically receive it whenever configuring a Request URL.
Once you receive the event, respond in plaintext with the challenge attribute value. In this example, that might be:
Retry Policy
Seismic will retry failed deliveries for up to 24 hours in the following order before discarding it.
- First retry: 1 minute after the initial request
- Second retry: 10 minutes after the first retry
- After the second retry, Seismic will retry every 1 hour for max 24 times.
Once you have successfully configured your request url, you can add one or many events.
Adding or Removing events
Any edits to a subscription will result in a new app version.
Seismic events have an event super-structure that all events will be wrapped around. Each event payload may differ event to event within the data object of the event itself.
| Object | Description |
|---|---|
| id | Unique id of the event |
| version | Version of the event |
| occurredAt | Timestamp of the event |
| tenantId | Tenant unique id (GUID) |
| tenantName | Tenant name |
| data | The container of the event details |
| application | Application responsible for the event |
| productArea | Product area of the event |
Responding to Events
Apps should respond to the event request with an HTTP 2xx within 10 seconds. Failure to respond to the event with result in a perceived failure. After a failure, we will begin retry sequence.
Any none 2xx response will be treated as a failure.
Failure Limits
While we strive to be tolerable to interruptions, we will proactively disable events subscriptions that are down for 48 hours.
Available events
Learn about all available types here - https://developer.seismic.com/seismicsoftware/docs/webhooksoverview
We are continually evaluating adding new events to our subscription. As events are added we will add them to the change log. If there specific events you'd like to see feel free to submit those to your Seismic representative for consideration.
Updated about 17 hours ago