Skip to main content

Webhooks

Webhooks let BrowserBee notify your systems when something important happens instead of requiring your application to poll continuously.

When webhooks are a good fit​

Use webhooks when:

  • your system reacts to BrowserBee changes
  • low-latency notification matters
  • polling would create unnecessary API traffic
  • you want to trigger downstream automation or synchronization

Receiver design defaults​

Every BrowserBee webhook receiver should:

  • authenticate or verify incoming delivery appropriately
  • acknowledge quickly
  • hand work off to an internal queue or worker when processing is expensive
  • tolerate duplicate delivery safely
  • log delivery attempts and failures clearly

Idempotency matters​

Event-based systems often see retries or duplicate deliveries. Your handler should be able to determine whether the event was already processed so that retrying delivery does not create inconsistent state.

Operational guidance​

Monitor:

  • delivery success rate
  • processing latency
  • retry volume
  • dead-letter or permanently failed deliveries

This is especially important once BrowserBee webhook traffic becomes part of a production-critical workflow.

Next steps​