Skip to main content

​
Why use webhooks

When building Brandfetch integrations, you might want your applications to receive events as they occur for brands you’re interested in, so that your backend systems can execute actions accordingly. To enable webhook events, you need to register webhook endpoints. After you register them, Brandfetch can push real-time event data to your application’s webhook endpoint when things happen. Brandfetch sends each event to your endpoint as a JSON POST over HTTPS. Deliveries follow version 1 of the Standard Webhooks specification, so you can verify them with an official library. Receiving webhook events is particularly useful for listening to asynchronous events such as when a brand’s logo changes, a company detail is updated, or when we index new data.

​
Pricing and eligibility

Webhooks are available on every paid plan, with no contract and no sales call. They do require an active paid subscription, either a self-serve plan or a custom contract: without one, creating a webhook is declined with the code NO_ACTIVE_SUBSCRIPTION and the message “Webhooks require an active paid subscription.” Registering an endpoint costs nothing, and neither does receiving deliveries, however many events your brands generate. What consumes API credits is each brand you subscribe a webhook to. The creation credit is consumed as soon as the subscription exists, even if you remove it moments later, and it is not pro-rated. There are no refunds, so removing a brand and adding it back charges again. A subscription you created during the current month has already paid for that month, and renews at the start of the next one.
Subscribing to brandfetch.com is free of credits, so you can wire up an endpoint and test it end to end without spending anything. The exemption covers credits only: the subscription still occupies one of your plan’s subscription slots, like any other.

​
Limits

Prepaid credit packs pay for subscription charges, but they do not raise the subscription limit; that limit follows your plan’s monthly allowance, so upgrading is what raises it. If your plan’s allowance is unlimited, this limit will not be a practical constraint. The subscription limit is checked when you add subscriptions, not maintained continuously, so a plan downgrade does not remove anything you already hold. What it changes is your next monthly renewal: if the renewal charge no longer fits your allowance plus any prepaid credits, your webhooks are paused, as described below. Delete unused endpoints before registering another.

​
When a renewal cannot be funded

Monthly renewals never spill into overage billing. They are paid from your monthly allowance plus any prepaid credits, and when that is not enough, we pause your organization’s webhooks rather than bill you for the difference. The same pause applies if the paid subscription itself lapses. While webhooks are paused:
  • Deliveries stop. Events that fire during the pause are skipped rather than held back, so they are not replayed once deliveries resume.
  • Creating webhooks and adding subscriptions are declined with the code BILLING_HOLD.
  • Your endpoints, their subscriptions, and their configuration all stay exactly as they were.
Removing subscriptions is re-checked during the removal, so it normally lifts the pause on the spot. Every remedy is also picked up by a daily check, which is where the 24 hour figure comes from.
Disabling a webhook stops its deliveries, but its subscriptions stay in place and keep renewing every month. Deleting the subscriptions is what stops the charge.
If a payment fails, your existing webhooks keep running and keep renewing, but new webhooks and new subscriptions are declined with the code PAYMENT_FAILED until you update your payment method.

​
Event overview

Brandfetch implements version 1.0.0 of the Standard Webhooks specification. Verify deliveries with the official Standard Webhooks libraries, or follow Verify without a library.
Brandfetch generates event data that we can send you to inform you of brand activity. When an event occurs, Brandfetch generates a new event object. A single API request might result in the creation of multiple events. For example, if we re-index a brand, you may receive brand.company.updated and brand.updated events. By registering webhook endpoints with Brandfetch, you enable us to automatically send event payloads as part of POST requests to the registered webhook endpoint hosted by your application. After your webhook endpoint receives the event payload, your app can run backend actions (for example, updating your database after you receive a brand.updated event).

​
Event payload

Each delivery carries a snapshot of the brand the event is about. It does not say which fields changed. If you need to know, compare the snapshot with the copy you stored. See the full list of event types that we can send to your webhook.

​
Example event payload

The following delivery reports an update to the Brandfetch brand. data.object is shortened here.

​
Request headers

Every delivery is a POST with these headers:

​
Event type

You receive events for all of the event types your webhook endpoint is listening for in your configuration. Use the received event type to determine what processing your application needs to perform. Every event you can subscribe to is a brand.* event, so data.object is always a brand.

​
Data object

data.object follows the shape of the Brand API response. Brandfetch reads the brand when the event happens, and every retry carries that same snapshot. Fetch the brand from the Brand API if you need its current state. A brand.deleted event reports a deleted brand, so its data.object carries only __typename, id, name, domain, and urn.