Pick the Bevy public API when your system needs to request or update data on demand. Pick webhooks when Bevy should push near-real-time updates to your HTTPS endpoint after subscribed records change. Many integrations use both.
Both tools move data between Bevy and systems you control. They answer different questions:
- Public API — your application asks Bevy for data or tells Bevy to change something, then waits for the response.
- Webhooks — Bevy sends JSON to an HTTPS URL you configure when subscribed records are created or updated (and, for some types, soft-deleted).
| Compare | Public API | Webhooks |
|---|---|---|
| Who starts the call | Your system. You send a request to Bevy and handle the response. | Bevy. Your endpoint receives a POST when a subscribed change is ready to deliver. |
| Pattern | Request and response (pull). You decide when to call and what to ask for. | Event-driven push. You listen for updates instead of polling for every change. |
| Timing | On demand. Latency depends on when you call and on rate limits. | Near real time after a subscribed change. Delivery is not a fixed clock interval. |
| Best fit | Lookups, writes, reports, backfills, and enriching a webhook payload with fields that were not included. | Automation that should react when members, events, attendees, chapters, or other subscribed objects change. |
| What you maintain | API key, requests, error handling, and any polling schedule you choose. | HTTPS endpoint, secret verification, fast acknowledgment, and retry-safe processing. |
When to choose the public API
Use the public API when your job starts in your system:
- You need a specific record or list right now (search, export, reconciliation).
- You need to create or update data in Bevy from another application.
- A webhook told you something changed, and you need more fields than the payload includes.
Start with Using Public Bevy APIs for base URL, authentication, versioning, responses, and rate limits. Endpoint details live in Bevy API Reference.
When to choose webhooks
Use webhooks when Bevy should notify you after a change, without your system polling:
- You want near-real-time updates for subscribed object types (for example attendees, users, events, or chapters).
- Your integration should react to those changes (sync a CRM, trigger automation, or queue follow-up work).
- You can host an HTTPS endpoint that verifies the webhook secret and returns success quickly.
Start with Introduction to Webhooks in Bevy and FAQs for how Bevy webhooks work, then use Configure webhooks and Webhooks best practices for setup and receiver design.
Note: Webhooks push a defined payload for each subscribed update type. They do not replace the API. If the payload is missing a field you need, call the public API for that record.
Using both together
A common pattern is:
- Configure webhooks so Bevy pushes when subscribed records change.
- Acknowledge the POST quickly on your endpoint.
- Call the public API when you need extra fields, a related object, or a write back into Bevy.
Tip: If you only need occasional exports or one-off updates, start with the public API. Add webhooks when polling becomes noisy, slow, or hard to keep in sync.