How to manage hook delivery attempts and retries
It is important to manage your Webhooks well. For this there are some tips and information that could be useful to you.
Select the events you want to receive
A smart selection of events received is the first thing to do. Think carefully about what events really matter to you. Indeed, having a webhooks that manage all the events can be tempting but it could quickly overload your
For example, if I need to know when a user is created through SCIM, I have to listen to the event dir_sync.user.provision.success.
The different status codes that you can return
The first thing to do when you receive an event is, of course, to send us a response with a 2xx code. But you can also use other codes that will be taken into account differently at Cryptr.
2xx codes
All codes between 199 and 300 not included are codes signifying successful sending. Cryptr will then interpret these responses as such and suppose that you have received the event.
410 Code
The 410 code is used to inform us that you wish to cancel the sending of an event. If you send us a 410 code then we will stop sending you this event.
4xx codes
For all other 4xx codes Cryptr will attempt to resend the event to you at different intervals which are as follows:
| Initial attempt | 0 |
|---|---|
| Attempt #1 | 5 minutes |
| Attempt #2 | 10 minutes |
| Attempt #3 | 20 minutes |
| Attempt #4 | 1 hour |
| Attempt #4 | 2 hours |
503 retry-after
This option, which can be included in the http header of your HTTP response you send us, allows you to define yourself a duration after which we will retry to send you the event.
To do this, simply send to us a 503 response code and include in the http header of your HTTP response the key retry-after followed by a value in seconds. For example:
{“retry-after”, 60}
This will restart sending an event to your
