Skip to content

Webhook backoff and retry behavior #72

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Webhook backoff and retry behavior #72

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
dbc0c6b
Merge remote-tracking branch 'refs/remotes/Microsoft/master'
darrelmiller Aug 20, 2016
8439b3d
Webhook backoff and retry behavior
darrelmiller Oct 5, 2016
25dfcde
Merge remote-tracking branch 'refs/remotes/Microsoft/master'
darrelmiller Oct 5, 2016
71d9a5d
Updated based on feedback from Working Group
darrelmiller Oct 8, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 11 additions & 4 deletions Guidelines.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1717,11 +1717,18 @@ Applications MUST be prepared to receive multiple events inside a single push no

The service MUST send all Web Hook data notifications as POST requests.

Services MUST allow for a 30-second timeout for notifications.
If a timeout occurs or the application responds with a 5xx response, then the service SHOULD retry the notification with exponential back-off.
All other responses will be ignored.
Services MUST allow for a 30-second request timeout for notifications for the initial subscription verification callback and then 10 secs for subsequent, regular notifications.
If a timeout occurs or the application responds with a 5xx response, then the service SHOULD retry the notification.
The retries SHOULD be done using exponential backoff, where the first retry occurs after 1 minute, and subsequent retries should double the interval each time.
A service should retry a maximum of 10 times.
This backoff algorithm will cause the last retry to be after an interval of approximately 8.5 hours, with a total elapsed time of approximately 17 hours.

The service MUST NOT follow 301/302 redirect requests.
New notification events, for the same recipient, that occur during this retry period SHOULD be aggregated into a single notification.

If the response contains a Retry-After header that is greater than interval determined by the backoff algorithm, then the Retry-After value SHOULD be respected.

If a service enables clients to unsubscribe from a webhook by returning a status code, it SHOULD use 410 to achieve this.
The service MUST NOT follow 3XX redirect requests.

#### 14.6.1 Notification payload
The basic format for notification payloads is a list of events, each containing the id of the subscription whose referenced resources have changed, the type of change, the resource that should be consumed to identify the exact details of the change and sufficient identity information to look up the token required to call that resource.
Expand Down