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 uses HTTPS to send webhook payloads to your app as a JSON payload that includes an Event object. The implementation follows the v1 of the Standard Webhooks specification. 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.
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

The event object we send to your webhook endpoint provides a snapshot of the object that changed. They might include a delta property that indicates the change, when applicable. See the full list of event types that we can send to your webhook.

​
Example event payload

The following event shows a subscription update at the end of a trial.

​
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. The data.object corresponding to each event type varies, but typically will be the namespace object (e.g. a Brand given brand.updated where brand.* is the event namespace.)

​
Data object and previous attributes delta

Event payloads may include a data.delta property which will indicate which fields changed. For *.updated events, the event payload always includes the data.delta property which will allow you to inspect what’s been updated on the object. The delta attributes in the example brand.updated event above indicates that the brand has a previous value of verified: false. The data.object property shows that the verified field has been set to true which indicates that the brand has been verified by Brandfetch’s curation team.