Stephen Turner
Akash Kumar
Jordan Lee
Taylor Scott
Sync Bridge bookings to your CRM or spreadsheet with the API
Use the Bridge API to copy every booking into your own system once, then check for changes every few minutes. Save each booking by its id, so reschedules and cancellations update the same record instead of creating duplicates.
What you end up with
A small scheduled job keeps a copy of your workspace's bookings in another system. New bookings appear, moved bookings update, and cancelled bookings get marked as cancelled.
Use this when the place you need bookings has no ready-made connection, such as an in-house database or a spreadsheet.
Before you start
- A Business or Enterprise workspace. API keys aren't available on other plans.
- A workspace owner, since only owners can create and see keys.
- A read only key, created in Settings → API keys. A sync never needs to change anything in Bridge.
- Somewhere safe for the key, such as your server's secret manager. Bridge shows the full key only once.
Four steps to the sync
Every booking has an updated_at time. It changes when a booking is created, rescheduled, cancelled or given a different host. The sync is built on that one field.
| Step | What to do |
|---|---|
| 1. Load everything once | Call GET https://api.meetonbridge.com/v1/bookings with the header Authorization: Bearer <key>. Use sort_by=updated_at, order=asc and take=100. Increase skip by 100 until pagination.has_more is false. |
| 2. Save by id | Use the booking id as the key. If that id exists, replace the record. If not, add it. |
| 3. Save a checkpoint | Note the time before each run starts. When it finishes, save that time minus 5 minutes. |
| 4. Check on a schedule | Every few minutes, make the same requests with after_updated_at set to your checkpoint. Page through until has_more is false, then save the new checkpoint. |
Why the five-minute overlap matters
A booking can change while your job is running, and two clocks can disagree slightly. The overlap catches both.
You will see some bookings twice as a result. That's harmless, because step 2 replaces the record instead of adding another.
How each change looks
| Change | What you see |
|---|---|
| New booking | An id you haven't seen, with status confirmed |
| Rescheduled | The same id with a new start and end; rescheduled_at shows when it moved |
| Cancelled | The same id with status cancelled; cancellation shows when, who and why |
| New host | The same id with a different hosts list |
Example: mapping bookings to a CRM
This mapping is an illustration, for a sales team that wants to act on bookings in its CRM. Your field names will differ.
| Bridge field | Example CRM use |
|---|---|
| attendee | Find or create the contact from email, name and phone |
| responses | Store intake answers on the meeting record |
| utm | Credit the campaign that sent the booking |
| booking_page | Route by page, such as demo or support |
| sms_consent | Respect whether the person agreed to text messages; it's null when no phone number was given |
| guests | Log extra invitees by email |
Mistakes to avoid
- Skipping cancelled bookings in the scheduled check. You can leave them out of the first load with status=confirmed, but keep them afterwards or you'll miss cancellations.
- Keying on email or start time. One person can book many times, and start times move.
- Matching on question text across time. Answers keep the wording from when the person booked, so renaming a question leaves older bookings with the old wording.
- Ignoring rate limits. Each key gets 120 requests per minute. On a 429 error, wait for the RateLimit-Reset seconds, then retry.
- Retrying a dead key forever. A key stops working if it's revoked (401), if its creator is no longer a workspace owner (403), or if the workspace moves to a plan without the API (403). Alert someone on these errors instead.
Test it before you rely on it
Book a test meeting on a page, then reschedule it, then cancel it. After each change, wait for the next run and check your system.
You should end up with one record, not three, showing the new time and then the cancelled status. To limit the sync to one page while testing, add booking_page_id to the request.