Retry behavior
A delivery attempt counts as failed when your endpoint answers with anything other than a 2xx status code, when it does not respond within 16 seconds, or when it cannot be reached at all. Brandfetch retries a failed delivery up to 15 times after the first attempt, so a single event gets at most 16 attempts against your endpoint, and the final attempt lands a little under eight days after the first. The wait between attempts widens as the retries progress: the first retry follows immediately, the next few are seconds and then minutes apart, the gaps after that stretch to several hours, and the last attempts are a day apart. An endpoint that is down for a weekend, or for several days, still receives the events it missed once it starts accepting deliveries again. Every attempt appears as its own entry in your delivery history, with the status code and any error message we recorded, so you can count the attempts made for an event and see what your endpoint returned each time. If your webhook has been disabled or deleted by the time a retry comes due, that retry and any remaining retries of the event are dropped. If you disable and then re-enable the webhook before the retry comes due, the retry is attempted as normal. When the last attempt fails, Brandfetch stops retrying that event and never sends it to your endpoint again. We email your organization’s contacts with the event type, the number of attempts made, and the status code we received on the final attempt. While an endpoint stays broken you receive at most one of these emails per webhook per week, however many events are abandoned in the meantime. A successful delivery clears that limit, so an endpoint that recovers and later breaks again is not left silent.Disable behavior
If your endpoint goes 14 consecutive days without accepting a single delivery, Brandfetch switches the webhook off and emails your organization’s contacts to tell you. The check runs on failed deliveries, so it is the first failure after the fourteenth day that switches the webhook off, and the email reports how long the endpoint had been failing along with the status code from that attempt. The 14 days are measured as an unbroken run of failures. Any successful delivery resets the count, so an endpoint that fails intermittently and then recovers is never switched off automatically; only one that has accepted nothing for two full weeks is. A webhook that has been switched off receives no further deliveries, including retries of events that were already scheduled. Its subscriptions are left in place: they stay active and keep renewing every month until you remove them, so removing the subscriptions is what ends the monthly charge for them. Because the subscriptions survive, you only need to fix your endpoint and setenabled back to true with the updateWebhook mutation to resume deliveries, with no need to subscribe again. Re-enabling also clears the failure history: the 14 day count starts again from the next failure, and so does the weekly limit on these emails.
If the attempt that trips the 14 day limit is also the attempt that exhausts an event’s retries, you receive this notice instead of the email about that abandoned event.
Event ordering
While events are usually in order, your integration should not depend on it. Brandfetch doesn’t guarantee delivery of events in the order in which they’re generated. For example, re-indexing a brand might generate the following events:brand.company.updatedbrand.updated
brand.company.updated if you happen to receive this event first).