Event notification retry

In order to increase the reliability of the communication of the event notification service, a retry mechanism is included. This means that if an event notification is not properly acknowledged by your server, the sending will be retried, thus ensuring a more robust integration.

Event queues and grouping

For the purpose of the retry mechanism, event types are grouped into the following separate queues:

Only message types configured for the event receiver will be sent.

Within a queue, events are guaranteed to be delivered in the order they were generated. This means that no subsequent events in any particular queue will be sent until the preceding event was sent successfully.

Acknowledging events

In order for an event to be considered successfully delivered, the recipient must respond to it with an HTTP 2xx response within 30 seconds. If the recipient responds with another HTTP response code, or does not respond at all, or responds too late, the event delivery is considered to be unsuccessful, and therefore it will be retried.

Typically a server responds with either HTTP 200 (OK) or HTTP 204 (no content). Other response codes in the 200-series are also accepted.

In addition to responding in a correct and timely manner, it is also required that the SSL certificate of the recipient is valid.

Retry mechanism

Events that could not be delivered successfully will be retried for 7 days, with an increasing backoff delay. Because events are guaranteed to be sent in order, an event that is being retried will block all subsequent events in the same queue, until it is successfully delivered (or until it has been retried for 7 days).

Events that can still not be delivered after retrying for 7 days will be discarded.

Frequently asked questions

What happens if my server is temporarily unavailable?

If the event can't be delivered, it will be retried, with increasing delays between the subsequent attempts. Any subsequent events for the same event type group will be queued, until the first one is successfully delivered. As soon as your server is available again, the initial event, and any queued events will be delivered.

What happens if there is a prolonged outage?

If the outage does not last longer than 7 days (minus the time it takes to process the backlog), all events will still be delivered.

If your server does not respond successfully to an event before it reaches the last retry attempt, the event will be discarded, and the next event will be sent.

I want to change the webhook credentials. How should I go about this?

You can modify the settings of your event receiver at any time, in the developer console. All delivery attempts, including retries, will use the updated settings with immediate effect.

In order to have a clean separation between events sent with old credentials and new credentials you could consider to temporarily stop receiving events while you amend the credentials. The procssing will catch up once the service is restored.

I made a mistake on my end with some events that I acknowledged. Can I receive them again?

No. We do not have any options to resend any successfully sent events.

I keep receiving the same event. Why is this?

The event notification service expects your webhook to respond with an HTTP 2xx status code within 30 seconds. Otherwise the notification will be retried, and you will receive it again.

I received an event twice despite having correctly and quickly acknowledged the first one. How is this possible?

It is possible that Drillster did not receive the acknowledgement due to a communications problem. In such case the event is not considered successfully sent and you will receive it again.

Can I temporarily pause the sending of event notifications?

No, you can't! However, it is safe to temporarily stop receiving and acknowledging events. As soon as your server comes back online event delivery will be resumed.

What happens if I don't process events fast enough?

If you are subscribed to an event type that sends a high volume of events, such as the QUESTION_ANSWERED event, it is important that your server is able to process these quickly enough to avoid building up a backlog spanning more than 7 days. Any events that sit in the queue for more than 7 days will be discarded.

As each notification contains an event timestamp as part of the payload, it is possible to determine whether there is a significant backlog of events or not.

Will you let me know if my server is unavailable?

No, it is your responsibility to ensure your server is up and running.

  • Copyright © 2006–2024 Drillster BV.