Zocdoc

Zocdoc's API is available exclusively to US healthcare providers and enterprise EHR systems with a formal partner relationship. Navigate to zocdoc.com/about/developer or contact Zocdoc directly to request API access. The enrollment process typically requires demonstrating that you are a licensed US healthcare provider, describing your integration use case, and agreeing to Zocdoc's partner terms including data handling requirements. During enrollment, clarify two things with your HIPAA compliance officer: (1) Can your practice store Zocdoc appointment data (patient names, provider, appointment times, reason for visit) in Bubble's database given Bubble's data hosting infrastructure? Bubble's data is hosted on AWS — confirm this satisfies your Business Associate Agreement (BAA) requirements. Bubble offers Business plans with a BAA for HIPAA-covered entities. (2) What is the minimum PHI necessary for your use case? A scheduling dashboard might only need a patient token (not the patient's full name) to display appointment counts and slot availability — minimizing PHI stored in Bubble reduces compliance burden. Once enrolled, Zocdoc provides a Bearer token for API authentication and documentation for the partner API endpoints (base URL https://api.zocdoc.com/v1). Build a Bubble app with mock appointment data while waiting for credentials so you can refine the UX immediately after credentials arrive.

In your Bubble editor, click the Plugins tab → Add plugins → search for 'API Connector' → install the API Connector by Bubble (free). After installation, click on API Connector and click 'Add another API'. Name this group 'Zocdoc'. Under Authentication, select 'None or self-handled'. Set the API base URL to https://api.zocdoc.com/v1. Click 'Add a shared header'. Set the key to Authorization and the value to Bearer YOUR_ZOCDOC_TOKEN (replace with your actual partner token, including the 'Bearer ' prefix with a space). CRITICAL: check the 'Private' checkbox next to this header. This is the core security mechanism — Bubble's server infrastructure holds this header value and never sends it to the browser. Your Bearer token stays private even when the Bubble app is accessed by patients on their own devices. Add a second header: Content-Type with value application/json (no Private flag needed — this is a standard technical header, not a credential). Verify the setup by looking at the API Connector configuration: the Authorization header should show the token value as masked dots when Private is checked. If you can still read the full token value, Private is not enabled — fix this before proceeding.

1{
2  "api_name": "Zocdoc",
3  "base_url": "https://api.zocdoc.com/v1",
4  "authentication": "None or self-handled",
5  "shared_headers": [
6    {
7      "key": "Authorization",
8      "value": "Bearer YOUR_ZOCDOC_PARTNER_TOKEN",
9      "private": true
10    },
11    {
12      "key": "Content-Type",
13      "value": "application/json",
14      "private": false
15    }
16  ]
17}

Within the Zocdoc API group, add your first call. Click 'Add another call'. Name it 'Get Provider Availability'. Set method to GET. The endpoint path should follow Zocdoc's partner documentation — typically something like /providers/{npi}/availability with date parameters. Check your Zocdoc partner documentation for the exact path. Add URL parameters: start_date (today's date in ISO 8601 format), end_date (date 7 days from now), and any other parameters Zocdoc requires (e.g., location, appointment_type). Set 'Use as' to 'Data'. Click 'Initialize call' and provide real test values for your provider's NPI and a valid date range. Bubble sends the request to Zocdoc using your Private credentials — the initialization response teaches Bubble the shape of the availability response (time slot objects with start_time, end_time, appointment_type, availability status). IMPORTANT: If initialization fails with 'There was an issue setting up your call', the Bearer token is most likely incorrect or the endpoint path differs from what you configured. Temporarily uncheck Private, click Initialize, open browser DevTools → Network tab to see the raw request/response, identify the error, fix it, then immediately re-check Private. Add a second call: 'Create Booking'. Method POST. Path /appointments (or the booking endpoint from Zocdoc's docs). Body: provider_id, patient details (if collected in Bubble), start_time, appointment_type. Set 'Use as' to 'Action'. Initialize with test data using Zocdoc's sandbox credentials if available. Add a third call: 'Get Appointments' (GET /appointments or /providers/{npi}/appointments) for the admin scheduling dashboard use case.

1// Call 1: Get Provider Availability
2{
3  "name": "Get Provider Availability",
4  "method": "GET",
5  "path": "/providers/<npi>/availability",
6  "use_as": "Data",
7  "parameters": [
8    { "key": "start_date", "value": "2026-07-09", "dynamic": true },
9    { "key": "end_date", "value": "2026-07-16", "dynamic": true },
10    { "key": "appointment_type", "value": "general", "dynamic": true }
11  ]
12}
13
14// Call 2: Create Booking (Action)
15{
16  "name": "Create Booking",
17  "method": "POST",
18  "path": "/appointments",
19  "use_as": "Action",
20  "body": {
21    "provider_npi": "<dynamic>",
22    "start_time": "<dynamic: selected slot time>",
23    "appointment_type": "<dynamic>",
24    "patient_token": "<dynamic: patient identifier>"
25  }
26}
27
28// Call 3: Get Appointments (Data)
29{
30  "name": "Get Appointments",
31  "method": "GET",
32  "path": "/appointments",
33  "use_as": "Data",
34  "parameters": [
35    { "key": "provider_npi", "value": "<dynamic>", "dynamic": true },
36    { "key": "start_date", "value": "<dynamic>", "dynamic": true },
37    { "key": "end_date", "value": "<dynamic>", "dynamic": true },
38    { "key": "limit", "value": "50" },
39    { "key": "offset", "value": "0", "dynamic": true }
40  ]
41}

Even if you minimize PHI stored in Bubble, the scheduling dashboard use case requires storing at minimum some appointment metadata. Create an Appointment Data Type in Bubble's Data tab with these fields: zocdoc_appointment_id (text — the Zocdoc identifier, never expose this as a public-facing URL parameter), appointment_time (date), provider_npi (text), appointment_type (text), status (text — confirmed, cancelled, pending), patient_identifier (text — use Zocdoc's patient token, not the patient's real name or DOB), created_via_webhook (yes/no), last_updated (date). Now configure Privacy rules for the Appointment type. Go to Data tab → Privacy tab → Appointment. Delete the default 'Anyone can view' rule if it exists. Add a new rule: 'This Appointment is visible when Current User is logged in AND Current User has a staff_role field of 'practice_admin' or 'scheduler''. For patient-facing portal use, add a second condition: 'OR Current User's patient_token = this Appointment's patient_identifier'. This allows patients to see only their own appointments, not other patients' data. Click 'Find fields exposed to others' in Bubble's Privacy panel. Every field should show 'None' for the 'Everyone else' column. If any field is marked as accessible to everyone, it is a HIPAA-relevant data exposure risk — fix it before going live. RapidDev has built multiple HIPAA-adjacent patient portal apps in Bubble — for complex multi-role access control or BAA questions, reach out for a free scoping call at rapidevelopers.com/contact.

Zocdoc can push booking events (booking_created, booking_cancelled) to a URL you register in the partner portal. In Bubble, this inbound URL is a Backend Workflow endpoint. Enable it: go to Settings (gear icon) → API tab → check 'Enable Workflow API'. This requires a paid Bubble plan — the checkbox does not appear on the free plan. After enabling, the endpoint namespace https://YOUR-APP.bubbleapps.io/api/1.1/wf/ is active. In the Workflow tab, click 'Backend Workflows'. Click 'New API Workflow' and name it 'zocdoc_webhook'. Add the step 'Detect request data'. Now you need to initialize this workflow with a real Zocdoc webhook payload. Go to your Zocdoc partner portal and register your Backend Workflow URL as the webhook endpoint. Then trigger a test webhook event from Zocdoc's partner tools — or manually send a POST to the /initialize URL: https://YOUR-APP.bubbleapps.io/api/1.1/wf/zocdoc_webhook/initialize With a sample payload like: { 'event_type': 'booking_created', 'appointment_id': 'appt_123', 'provider_npi': '1234567890', 'slot_time': '2026-07-10T14:00:00Z', 'patient_token': 'pt_abc456', 'status': 'confirmed' }. After successful initialization, add a workflow step: Branch on request_data's event_type. If 'booking_created': Create a new Appointment with the detected fields. If 'booking_cancelled': Search for Appointment where zocdoc_appointment_id = request_data's appointment_id, then modify it to set status = 'cancelled'. Add a Return data from API step returning { 'status': 'received' } with HTTP status 200. Register the production URL (https://YOUR-APP.bubbleapps.io/api/1.1/wf/zocdoc_webhook — no /initialize suffix) in the Zocdoc partner portal as your booking event webhook.

1// Sample Zocdoc webhook payload for Backend Workflow initialization
2// POST to: https://YOUR-APP.bubbleapps.io/api/1.1/wf/zocdoc_webhook/initialize
3{
4  "event_type": "booking_created",
5  "appointment_id": "appt_test_123",
6  "provider_npi": "1234567890",
7  "slot_time": "2026-07-10T14:00:00Z",
8  "appointment_type": "general_consultation",
9  "patient_token": "pt_abc456",
10  "status": "confirmed",
11  "created_at": "2026-07-09T10:30:00Z"
12}
13
14// Production webhook endpoint (no /initialize suffix):
15// https://YOUR-APP.bubbleapps.io/api/1.1/wf/zocdoc_webhook

Create a new page for the patient-facing booking experience. Add a Date Picker element for the patient to select their preferred appointment date. Wire the date picker value to a 'Get Provider Availability' API call: configure the call's start_date parameter as 'Date Picker's value' formatted as ISO 8601, and end_date as 'Date Picker's value + 1 day'. Add a Repeating Group below the date picker. Set the data source to 'Get Provider Availability' from the Zocdoc API, filtered by the date picker value and your provider's NPI. Inside each cell, display the slot time formatted in the patient's local timezone — use Bubble's date formatting with the 'User's browser timezone' option. Add a 'Book This Slot' button. The button workflow: (1) Call Zocdoc 'Create Booking' action with the selected slot's start_time, appointment_type, and the patient's identifier from Bubble's Current User record. (2) On success, show a confirmation popup with the appointment details. (3) On error, show an error popup with a message to try another slot. For timezone display: Zocdoc availability times are in the provider's local timezone. Patients in different timezones may see confusing times. Use Bubble's 'Convert date to timezone' expression to display slots in the patient's local time. Add a small text below each slot showing the patient's timezone (e.g., 'Eastern Time') so patients can confirm they selected the right time. Do not cache the availability slots in Bubble's database — they can change between page loads as other patients book the same provider. Fetch live on each page interaction. If a patient selects a slot that was just booked by another patient, the Create Booking call will return an error — handle this gracefully with a message like 'This slot was just taken — please choose another time' and refresh the availability list.