Skip to main content
Saasybill delivers each event at least once. If your server doesn’t acknowledge it, Saasybill tries again for about 20 hours.

​
What counts as success

Saasybill reads at most 500 characters of your response body, to show you in the delivery log.

​
Retry schedule

A failed delivery is tried again after a delay that grows each time. There are seven attempts in about 20 hours. Up to 20% extra delay is added to each wait, so one recovering server isn’t hit by every queued event at the same second. Retries run on a one-minute cycle, so a delay means “no sooner than”. After the seventh failure the delivery is Failed. It stays in the delivery log for 30 days. The Saasybill-Delivery-Attempt header tells you which attempt a request is.

​
Duplicates and order

Because delivery is at-least-once, the same event can arrive more than once. It also can arrive after a newer event.
  • Skip repeats. Store the Saasybill-Event-Id of each event you have processed. If you see it again, reply 200 and do nothing.
  • Don’t rely on order. If two events about the same object arrive in the wrong order, act on the object’s current state. Fetch it from the API.
  • Keep handlers idempotent. Processing an event twice should have the same effect as processing it once.
Retries send the same body, so the signature stays valid. The t in the signature header is refreshed on every attempt.

​
The delivery log

Every attempt is recorded. Open Developer Settings, then Webhooks, then Recent Deliveries. Each delivery shows its event type, the endpoint’s host, and a status. Click a delivery to see each attempt: the status code (or No response), how long it took, any error, and the start of your response body.

​
Send an event again

Click Send Again on a delivery to send the same event to the endpoint straight away. Use it after you’ve fixed a problem, to catch up on an event you missed.

​
Errors you might see

Saasybill describes a failure in plain terms, without exposing anything about your network.

​
An endpoint that never works is switched off

If 5 events in a row can’t be delivered at all, with no success between them, Saasybill switches the endpoint off. Every attempt at each of those events must have failed.
  • The Webhooks page shows a banner and says why on the endpoint.
  • Nobody is emailed. Check the page from time to time, or monitor your endpoint yourself.
  • Click Turn On once the problem is fixed. This doesn’t replay what was missed.
  • To catch up, use Send Again on each missed delivery, or fetch the objects from the API.
Events that happen while an endpoint is off are not sent to it later. If your endpoint has been off, reconcile from the API: list recent subscriptions and invoices and compare them with your records.

​
Design for reliability

Acknowledge, then work

Reply 200 first. Put the event on a queue and process it in the background.

Store the event id

Keep the ids you’ve processed so a repeat does nothing.

Fetch, don't trust

Read the object’s current state from the API. Don’t depend on the order events arrive in.

Reconcile now and then

Run a periodic job that lists recent objects and repairs anything you missed.