How to Integrate Bolt.new with Doodle

Before investing time in integration work, it is important to understand exactly what is and is not available with Doodle for independent developers. Doodle's API documentation at developer.doodle.com describes a REST API, but this API is not open for independent developers — it requires an enterprise partnership agreement with Doodle's business team. Individual developers cannot register for API access, generate API keys, or test the API endpoints. The features described in Doodle's API documentation (creating polls, fetching participants, retrieving votes) are not accessible to apps built on Bolt.new. This is a deliberate business decision by Doodle to protect their scheduling data and avoid commoditization of their core product. For Bolt.new integrations, there are three viable paths, each with different trade-offs. The embed approach is zero-effort: create the poll manually on Doodle, copy the embed code or URL, and include it in your app as an iFrame. Participants vote in the embedded Doodle interface, but your app has no access to the vote data. This works for informational pages where you just want to display a scheduling poll. The Supabase custom poll approach requires the most upfront work but gives you full ownership of the feature — create polls programmatically, store votes in your own database, calculate results, send notifications, and integrate with your app's user authentication. This is the recommended path when scheduling is a core feature of your app and you need complete control. The Calendly API approach is the best choice when the scheduling model is one-on-one appointment booking (someone books time on your calendar) rather than group consensus polling. Calendly has a fully open REST API with personal access tokens, making it straightforward to integrate from Bolt.

1// .env.local — for Supabase custom poll approach
2NEXT_PUBLIC_SUPABASE_URL=your_supabase_project_url
3NEXT_PUBLIC_SUPABASE_ANON_KEY=your_supabase_anon_key
4
5// For Calendly API approach (added in later steps)
6CALENDLY_ACCESS_TOKEN=your_calendly_personal_access_token
7CALENDLY_EVENT_TYPE_UUID=your_event_type_uuid

A custom scheduling poll needs two database tables: one for polls (with the organizer's details, the list of candidate time slots, and expiration date) and one for votes (recording each participant's name, email, and the slots they selected as available). The time slots are stored as a JSONB array in Supabase, where each slot is an object with a unique ID, a label string, and an ISO datetime value. The poll creation flow: the organizer fills out a form with a poll title, their name, and the candidate time slots (as many as 10 is a reasonable limit). Your app creates a poll record in Supabase and returns the poll ID. The organizer shares a link like your-app.com/schedule/[pollId] with participants. The voting flow: participants open the shared link, see the list of candidate time slots, and check the slots that work for them. They enter their name and email for identification. Your app inserts a vote record linking their selections to the poll. The schema uses a text array for available_slots to store the slot IDs the participant selected. The results flow: once enough participants have voted, the organizer opens the poll URL and sees a results view — each time slot with a count of how many participants selected it, with the highest-vote slot highlighted. Optionally, the organizer clicks 'Confirm meeting time' which marks the poll as decided and sends confirmation emails. Because Supabase uses HTTP-based communication (via the PostgREST API), the entire custom poll feature works in Bolt's WebContainer without any deployment needed during development.

1-- Supabase SQL: Group scheduling tables
2CREATE TABLE scheduling_polls (
3  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
4  organizer_name TEXT NOT NULL,
5  organizer_email TEXT NOT NULL,
6  title TEXT NOT NULL,
7  description TEXT,
8  time_slots JSONB NOT NULL, -- [{id: 'slot1', label: 'Mon Jun 9, 2pm', datetime: '2026-06-09T14:00:00Z'}]
9  status TEXT DEFAULT 'open' CHECK (status IN ('open', 'closed', 'decided')),
10  decided_slot_id TEXT,
11  created_at TIMESTAMPTZ DEFAULT now(),
12  expires_at TIMESTAMPTZ
13);
14
15CREATE TABLE poll_votes (
16  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
17  poll_id UUID REFERENCES scheduling_polls(id) ON DELETE CASCADE NOT NULL,
18  participant_name TEXT NOT NULL,
19  participant_email TEXT NOT NULL,
20  available_slots TEXT[] NOT NULL, -- Array of slot IDs the participant is available for
21  voted_at TIMESTAMPTZ DEFAULT now(),
22  UNIQUE(poll_id, participant_email) -- One vote per participant per poll
23);
24
25-- RLS: Anyone can read polls and votes (participants need no account)
26ALTER TABLE scheduling_polls ENABLE ROW LEVEL SECURITY;
27ALTER TABLE poll_votes ENABLE ROW LEVEL SECURITY;
28
29CREATE POLICY "Public read polls" ON scheduling_polls FOR SELECT USING (true);
30CREATE POLICY "Public insert polls" ON scheduling_polls FOR INSERT WITH CHECK (true);
31CREATE POLICY "Public read votes" ON poll_votes FOR SELECT USING (true);
32CREATE POLICY "Public insert votes" ON poll_votes FOR INSERT WITH CHECK (true);

With votes stored in Supabase, calculating the optimal meeting time is straightforward: count how many votes included each slot ID, then rank the slots by vote count. The slot with the highest count is the best meeting time. In case of a tie, secondary sorting by earlier datetime is a sensible tiebreaker. The results calculation happens client-side using the data fetched from Supabase. Fetch all votes for a poll using the Supabase JavaScript client: supabase.from('poll_votes').select('available_slots, participant_name').eq('poll_id', pollId). Then iterate through votes and count occurrences of each slot ID. Display the results as a ranked list of time slots with: the slot label, a count like '4 of 6 participants available', a visual progress bar showing the percentage, and a 'Best' badge on the top-ranked slot. For slots where everyone is available, show an 'All available' indicator. For sending confirmation notifications when the organizer decides on a time, use the SendGrid or Resend API from a server-side API route. Send an email to each participant with the confirmed meeting time. This requires a deployed app (outbound email works from the WebContainer during development, but production use should go through a proper transactional email service). The UI should also show who voted and which slots they are available for — this social proof helps participants coordinate and sometimes prompts people who have not voted to do so.

1// lib/scheduling/calculateResults.ts
2type TimeSlot = { id: string; label: string; datetime: string };
3type PollVote = { participant_name: string; available_slots: string[] };
4
5export type SlotResult = {
6  slot: TimeSlot;
7  availableCount: number;
8  totalVotes: number;
9  availabilityPercent: number;
10  participants: string[];
11  isBest: boolean;
12};
13
14export function calculateSlotResults(
15  timeSlots: TimeSlot[],
16  votes: PollVote[]
17): SlotResult[] {
18  const totalVotes = votes.length;
19
20  const results = timeSlots.map((slot) => {
21    const availableVotes = votes.filter((v) =>
22      v.available_slots.includes(slot.id)
23    );
24    return {
25      slot,
26      availableCount: availableVotes.length,
27      totalVotes,
28      availabilityPercent:
29        totalVotes > 0 ? Math.round((availableVotes.length / totalVotes) * 100) : 0,
30      participants: availableVotes.map((v) => v.participant_name),
31      isBest: false,
32    };
33  });
34
35  // Sort by availability count desc, then by datetime asc for tiebreaker
36  results.sort((a, b) => {
37    if (b.availableCount !== a.availableCount) return b.availableCount - a.availableCount;
38    return new Date(a.slot.datetime).getTime() - new Date(b.slot.datetime).getTime();
39  });
40
41  // Mark the best slot
42  if (results.length > 0 && results[0].availableCount > 0) {
43    results[0].isBest = true;
44  }
45
46  return results;
47}

Deploying your custom scheduling app follows the standard Bolt workflow. Click the Publish button in Bolt's top-right corner to deploy to Netlify with a .netlify.app URL. After deployment, add your Supabase environment variables in Netlify's Site Settings → Environment Variables: NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY. These are safe to use with the NEXT_PUBLIC_ prefix since Supabase anon keys are designed to be public — Row Level Security handles authorization at the database level. For participants accessing the poll voting page, no account or authentication is required. The RLS policies set in step 2 allow public read and insert access on both tables, so anyone with the poll link can vote. If you want to restrict who can create new polls (to prevent spam), add authentication to the poll creation form using Supabase Auth while keeping the voting page public. As an alternative to the custom poll build, Calendly provides the best open API in the scheduling space. If your use case is appointment booking (one person books available time on another person's calendar) rather than consensus-style group scheduling, Calendly's REST API is excellent. Get a personal access token from developer.calendly.com and use it to: retrieve available event types, generate one-time scheduling links, and receive webhooks when appointments are booked. The Calendly API webhook notifies your server when a new invitee is created (someone books a meeting) or when an event is canceled. Like all webhooks, this requires a deployed public URL — Bolt's WebContainer cannot receive incoming webhook requests during development. Deploy first, then register your webhook URL in the Calendly developer console with the events you want to subscribe to: invitee.created and invitee.canceled.

1// app/api/calendly/create-link/route.ts
2import { NextResponse } from 'next/server';
3
4const CALENDLY_API = 'https://api.calendly.com';
5const ACCESS_TOKEN = process.env.CALENDLY_ACCESS_TOKEN;
6const EVENT_TYPE_UUID = process.env.CALENDLY_EVENT_TYPE_UUID;
7
8export async function POST() {
9  // First, get the current user's URI (needed for single-use links)
10  const meRes = await fetch(`${CALENDLY_API}/users/me`, {
11    headers: { Authorization: `Bearer ${ACCESS_TOKEN}` },
12  });
13
14  if (!meRes.ok) {
15    return NextResponse.json({ error: 'Calendly auth failed' }, { status: 401 });
16  }
17
18  const { resource: user } = await meRes.json();
19
20  // Create a single-use scheduling link
21  const linkRes = await fetch(`${CALENDLY_API}/scheduling_links`, {
22    method: 'POST',
23    headers: {
24      Authorization: `Bearer ${ACCESS_TOKEN}`,
25      'Content-Type': 'application/json',
26    },
27    body: JSON.stringify({
28      max_event_count: 1, // Single-use link
29      owner: `${CALENDLY_API}/event_types/${EVENT_TYPE_UUID}`,
30      owner_type: 'EventType',
31    }),
32  });
33
34  if (!linkRes.ok) {
35    const error = await linkRes.json();
36    return NextResponse.json({ error }, { status: linkRes.status });
37  }
38
39  const { resource } = await linkRes.json();
40  return NextResponse.json({ schedulingUrl: resource.booking_url });
41}