> ## Documentation Index
> Fetch the complete documentation index at: https://docs.brandfetch.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Get notified of changes by receiving events at your webhook URL.

## 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](/delivery-methods/webhooks/setup#register-your-endpoint). 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](https://github.com/standard-webhooks/standard-webhooks/blob/main/spec/standard-webhooks.md) 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.

| Action                                              | Cost                              |
| --------------------------------------------------- | --------------------------------- |
| Registering a webhook endpoint                      | Free                              |
| Receiving event deliveries                          | Free, at any volume               |
| Subscribing a webhook to a brand                    | 1 API credit, charged on creation |
| Holding that subscription into a new calendar month | 1 API credit per month            |
| Subscribing to `brandfetch.com`                     | Free of credits                   |

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.

<Note>
  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.
</Note>

### Limits

| Limit                                                         | Value                                    |
| ------------------------------------------------------------- | ---------------------------------------- |
| Brand subscriptions held at once, across all of your webhooks | Your plan's monthly API credit allowance |
| Webhook endpoints per organization                            | 100                                      |

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.

| Denial                                                      | Code                    |
| ----------------------------------------------------------- | ----------------------- |
| Adding subscriptions past the subscription limit            | `CAPACITY_EXCEEDED`     |
| Adding more subscriptions than your remaining credits cover | `INSUFFICIENT_CREDITS`  |
| Registering an endpoint when you already hold 100           | `WEBHOOK_LIMIT_REACHED` |

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.

| What you do                                            | When deliveries resume                                           |
| ------------------------------------------------------ | ---------------------------------------------------------------- |
| Remove enough subscriptions to fit within your credits | Usually as part of the removal itself, otherwise within 24 hours |
| Buy more credits, or upgrade your plan                 | Within 24 hours                                                  |
| Restore a lapsed paid subscription                     | Within 24 hours                                                  |

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.

<Warning>
  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.
</Warning>

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

<Info>
  Brandfetch implements version 1.0.0 of [the Standard
  Webhooks](https://github.com/standard-webhooks/standard-webhooks/blob/main/spec/standard-webhooks.md)
  specification.
</Info>

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](/delivery-methods/webhooks/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.

<CodeGroup>
  ```JSON JSON theme={null}
  {
    "type": "brand.updated",
    "timestamp": "2024-01-01T00:00:00.000000Z",
    "urn": "urn:brandfetch:organization:0123:webhook:1234:event:2345",
    "data": {
      "object": { "__typename": "Brand", "id": "id123456", "domain": "brandfetch.com", "verified": true, ... },
      "delta": { "verified": { "old": false, "new": true } }
    }
  }
  ```

  ```TypeScript TypeScript theme={null}
  interface WebhookEventPayload {
    readonly type: string;
    readonly timestamp: string;
    readonly urn: string;
    readonly data: {
      readonly object: Record<string, string>;
      readonly delta: Record<string, { readonly old: any; readonly new: any }>;
    };
  }
  ```
</CodeGroup>

### 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.