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.createdbrowser_profile.updatedbrowser_profile.activatedbrowser_profile.deprecatedbrowser_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:
- subscribe only to the events your downstream automation uses
- terminate TLS on the receiving endpoint
- store the signing secret in the same secret store as your API tokens
- 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.