How to Integrate Lovable with Zocdoc

Zocdoc's Partner API is not self-serve — it's a B2B partnership program. Go to zocdoc.com/about/partner-api and click 'Become a Partner'. You'll complete a form describing your application, your company, how you plan to use Zocdoc's API, your expected user volume, and your technical architecture. Zocdoc evaluates applications based on the legitimacy of the use case and the potential mutual value. The approval process typically takes 1-2 weeks and may include a call with Zocdoc's partnership team to discuss your use case in detail. Approved partners receive API documentation, a partner API key, and technical onboarding support from Zocdoc's team. Zocdoc's partnership team is the primary point of contact for API documentation details, endpoint specifics, and compliance requirements. During the application, clearly articulate how your application improves patient access to care — Zocdoc's mission is improving healthcare access, and applications that align with this mission are more likely to be approved. Examples of strong use cases: helping uninsured or underinsured patients find affordable care, improving appointment adherence for patients with chronic conditions, or helping employees find in-network care to reduce out-of-pocket costs. While waiting for approval, focus on building your app's non-Zocdoc features and preparing the UI mockups for the booking flow. This ensures you're ready to integrate quickly once credentials arrive.

After Zocdoc approves your partnership and provides API credentials, open your Lovable project, click '+', select 'Cloud', and expand Secrets. Add ZOCDOC_API_KEY with your partner API key. Add ZOCDOC_API_BASE with the API base URL provided by Zocdoc (typically https://api.zocdoc.com/partners/v2 or similar — use the exact URL from your onboarding documentation). Zocdoc API keys grant access to their provider database and booking infrastructure. These keys are associated with your partnership agreement and grant access to Zocdoc's real patient booking system — any appointments booked through your API key create real bookings in providers' calendars. Treat these credentials with the highest security. For development and testing, ask your Zocdoc partner contact for a sandbox environment with test provider data. This allows you to test booking flows without creating real appointments. Zocdoc's sandbox typically mirrors the production API but returns test data that doesn't affect real providers' calendars.

Create a Supabase Edge Function that proxies Zocdoc provider search requests. Provider search is the core discovery feature: given a specialty, location, and optionally insurance plan and gender preference, return a list of matching providers with their next available appointment times. Zocdoc's search endpoint typically accepts: specialty (specialty name or code), address/zip (patient location for proximity sorting), insurance_plan (insurance carrier and plan name), gender, and date_range (for filtering availability). The response includes provider profiles with name, credentials, specialty, practice location, distance from the searched location, patient reviews/ratings, and real-time appointment slot availability. For each provider in the results, Zocdoc returns the next available appointment time — this is a key differentiator from generic doctor directories. Displaying 'Next available: Tomorrow at 2 PM' versus 'Next available: In 3 weeks' directly affects which provider a patient chooses, and it's what makes Zocdoc data valuable. Structure your Edge Function to accept the search parameters, call the Zocdoc search endpoint with the API key in the Authorization header (or header specified in your Zocdoc documentation), and return cleaned, structured provider data to your frontend.

1// supabase/functions/zocdoc-api/index.ts
2import { serve } from "https://deno.land/std@0.168.0/http/server.ts";
3
4const API_KEY = Deno.env.get("ZOCDOC_API_KEY") ?? "";
5const BASE = Deno.env.get("ZOCDOC_API_BASE") ?? "";
6const corsHeaders = { "Access-Control-Allow-Origin": "*", "Access-Control-Allow-Methods": "POST, OPTIONS", "Access-Control-Allow-Headers": "Content-Type, Authorization" };
7
8const zdFetch = (path: string, options?: RequestInit) =>
9  fetch(`${BASE}${path}`, { ...options, headers: { "Authorization": `Bearer ${API_KEY}`, "Content-Type": "application/json", ...((options?.headers ?? {}) as Record<string, string>) } });
10
11serve(async (req) => {
12  if (req.method === "OPTIONS") return new Response(null, { headers: corsHeaders });
13  try {
14    const body = await req.json();
15    const { action } = body;
16
17    if (action === "search-providers") {
18      const { specialty, zip_code, insurance_carrier, insurance_plan } = body;
19      const params = new URLSearchParams({ specialty, address: zip_code });
20      if (insurance_carrier) params.set("insurance_carrier", insurance_carrier);
21      if (insurance_plan) params.set("insurance_plan", insurance_plan);
22      const res = await zdFetch(`/providers?${params}`);
23      const data = await res.json();
24      // Map response to standardized format — exact field names depend on Zocdoc's API version
25      const providers = (data.providers ?? data.results ?? []).map((p: any) => ({
26        provider_id: p.id ?? p.provider_id,
27        name: p.name ?? `${p.first_name} ${p.last_name}`,
28        specialty: p.specialty ?? "",
29        practice_name: p.practice?.name ?? "",
30        address: p.practice?.address?.full_address ?? "",
31        distance_miles: p.distance ?? null,
32        rating: p.rating ?? null,
33        next_available_slot: p.next_available_slot ?? null,
34      }));
35      return new Response(JSON.stringify({ providers }), { headers: { ...corsHeaders, "Content-Type": "application/json" } });
36    }
37
38    return new Response(JSON.stringify({ error: "Unknown action" }), { status: 400, headers: corsHeaders });
39  } catch (err) {
40    return new Response(JSON.stringify({ error: err.message }), { status: 500, headers: { ...corsHeaders, "Content-Type": "application/json" } });
41  }
42});

With the Edge Function working, build the booking UI. The core flow is: specialty search → provider list → availability calendar → patient info form → confirmation. Create a search page with: a specialty dropdown or text input (either a predefined list of medical specialties or free text search), a location field (zip code or city), and optional insurance filters. On search submit, call the zocdoc-api Edge Function and display results as provider cards. Each provider card should show: provider photo placeholder or Zocdoc's provider image URL if available, provider name and credentials, specialty and subspecialty, practice name and address, rating stars and review count, and a prominent 'Book Appointment' button showing the next available slot time. The booking modal shows: a date picker or calendar with available days highlighted, time slots for the selected day, a form for patient details (name, DOB, insurance ID, reason for visit), and a confirmation screen showing all booking details before final submission. After booking, store the appointment details in a Supabase appointments table with: user_id, provider_id, provider_name, appointment_time, confirmation_number, status. This allows your app to show appointment history and upcoming bookings independently of calling the Zocdoc API.