Skip to main content
  1. Documentation/
  2. Core concepts/

Webhooks

Use BrowserBee webhooks to react to profile lifecycle events without polling the API.

Why use webhooks
#

Webhooks allow BrowserBee to notify your systems when profile state changes, which reduces polling and helps your automation react faster.

Current event types include:

  • browser_profile.created
  • browser_profile.updated
  • browser_profile.activated
  • browser_profile.deprecated
  • browser_profile.deleted

Registration model
#

Register a webhook by sending a destination URL and at least one event:

{
  "webhook": {
    "url": "https://example.com/browserbee/events",
    "events": [
      "browser_profile.updated",
      "browser_profile.deprecated"
    ]
  }
}

BrowserBee returns a signing secret when the webhook is created. That secret is returned once, so save it before you leave the response.

Recommended customer defaults#

Start with a narrow event set and expand only when the receiver proves reliable:

  1. subscribe only to the events your downstream automation uses
  2. terminate TLS on the receiving endpoint
  3. store the signing secret in the same secret store as your API tokens
  4. log delivery failures with the BrowserBee webhook ID so support and engineering can trace problems quickly

When to prefer polling
#

If your rollout is still exploratory and you only need occasional inventory syncs, listing resources on a schedule can be enough. Move to webhooks once profile changes need to trigger downstream work automatically.