DEV Community: SlotKit

The double-booking bug I shipped in my Next.js booking app (and how Postgres fixed it)

SlotKit — Mon, 19 Oct 2026 22:42:33 +0000

I build a multi-tenant booking template with Next.js, Drizzle and Postgres. During an audit I found that my "double booking protection" didn't protect anything. Here's the bug, and the fix.

The naive version

This is roughly what I had:

const conflict = await db.select().from(bookings).where(
  and(
    eq(bookings.resourceId, resourceId),
    gte(bookings.startTime, start),
    lte(bookings.endTime, end),
  )
)
if (conflict.length > 0) throw new Error('SLOT_NOT_AVAILABLE')

await db.insert(bookings).values({ resourceId, startTime: start, endTime: end })

It looks fine. It has three bugs.

Bug 1: check-then-insert isn't atomic

Two requests for the same slot arrive at the same time. Both run the SELECT, both see no conflict, both INSERT. On serverless, where many instances run in parallel, this isn't theoretical.

Bug 2: the overlap condition is wrong

start >= A && end <= B only catches bookings fully inside the new one. A booking from 10:15 to 10:45 doesn't block a new one from 10:00 to 10:30. Two intervals overlap when:

existing.start < new.end && existing.end > new.start

Strict comparisons also mean back-to-back slots (10:00–10:30 and 10:30–11:00) are allowed, as they should be.

Bug 3: cancelled bookings still count

No status filter, so a cancelled booking blocked its slot forever.

The fix: a transaction-scoped advisory lock

Postgres advisory locks let you lock an arbitrary key. Locking on the resource ID serialises bookings for that resource only, while other resources keep booking in parallel:

await db.transaction(async (tx) => {
  // Released automatically at commit/rollback
  await tx.execute(sql`select pg_advisory_xact_lock(hashtext(${resourceId}))`)

  const conflict = await tx.select({ id: bookings.id }).from(bookings).where(
    and(
      eq(bookings.resourceId, resourceId),
      ne(bookings.status, 'cancelled'),
      lt(bookings.startTime, end),
      gt(bookings.endTime, start),
    )
  ).limit(1)

  if (conflict.length > 0) throw new SlotNotAvailableError()

  await tx.insert(bookings).values({ resourceId, startTime: start, endTime: end })
})

The second request waits on the lock, then sees the first booking and fails cleanly with a 409 instead of creating a duplicate.

Why not a unique constraint? Bookings are ranges, and two different start times can still overlap, so a unique index on start_time doesn't help. An exclusion constraint with btree_gist is the other solid option. I chose the advisory lock because it needs no extension and keeps the logic readable in one place.

Serverless note: with Supabase's transaction pooler (port 6543), configure postgres.js with prepare: false. A transaction-scoped lock works fine there, because the whole transaction runs on one connection.

Bonus: the timezone bug next door

new Date('2026-10-20T10:00:00') is parsed in the server's timezone, which is UTC on Vercel. A salon in Rome opening at 10:00 was storing 10:00 UTC. The fix was converting the business's wall-clock time to UTC with Intl.DateTimeFormat and the tenant's IANA timezone, including a second pass to handle DST changes.

Takeaway

If your "is this slot free?" logic is a SELECT followed by an INSERT, you have a race condition. Put both in a transaction and lock on what you're protecting.

This came out of hardening SlotKit, a Next.js booking template for agencies. There's a live demo if you want to try booking a slot twice.

Update (v1.5.2): as Arjun Sharma pointed out in the comments, an unbounded lock wait means one stuck transaction can queue every booking for that resource. The fix is to bound the wait inside the transaction:

await tx.execute(sql.raw(`SET LOCAL lock_timeout = '5000ms'`))
await tx.execute(sql`select pg_advisory_xact_lock(hashtext(${resourceId}))`)

SET LOCAL (not SET) matters behind a transaction pooler: the setting dies with the transaction instead of leaking to the next client. When it fires, Postgres raises 55P03 and the API returns a 503 "try again".

This came out of hardening SlotKit, a Next.js multi-tenant booking template for agencies serving clinics and medical practices. The fix above is covered by an automated test that fires 10 simultaneous bookings at one slot. Try the live demo, or get the template with 20% off until November 8 (code DEVTO20).

How to build a race-condition-proof booking system with Drizzle ORM and PostgreSQL

SlotKit — Fri, 05 Jun 2026 17:52:58 +0000

Update (October 2026): I later found that a transaction alone doesn't prevent double bookings under Postgres's default isolation level. The fix — a transaction-scoped advisory lock — is explained here: The double-booking bug I shipped (and how Postgres fixed it). SlotKit now runs on Next.js 16.

Booking systems look simple until two customers try to
book the same slot at the same millisecond.

You check availability. Slot is free. You create the booking.

Meanwhile, another user did the exact same thing — same slot,
same resource, same moment. Now you have a double booking, an
angry customer, and a support ticket you didn't need.

This is a race condition, and it's one of the most common bugs
in booking systems built by developers who haven't dealt with it
before. Here's how to solve it correctly with Drizzle ORM and
PostgreSQL.

I ran into this building SlotKit — a booking SaaS template
for agencies. After the third time debugging a double booking
in staging, I stopped patching and fixed it properly.

Why the naive approach fails

The naive approach looks like this:

// ❌ This is wrong
async function createBooking(input: CreateBookingInput) {
  // Step 1: check if slot is available
  const conflict = await db
    .select()
    .from(bookings)
    .where(
      and(
        eq(bookings.resourceId, input.resourceId),
        gte(bookings.endTime, startDateTime),
        lte(bookings.startTime, endDateTime)
      )
    )

  if (conflict.length > 0) {
    throw new Error('SLOT_NOT_AVAILABLE')
  }

  // Step 2: create the booking
  await db.insert(bookings).values({ ... })
}

The problem: between Step 1 and Step 2, another request can
sneak in. Both requests pass the availability check. Both
create a booking. Double booking confirmed.

This isn't a theoretical problem — it happens in production
whenever your app gets moderate traffic, especially during
popular booking windows like Monday mornings or post-holiday
reopenings.

The correct solution: database transactions

The fix is to wrap the availability check and the booking
creation in a single database transaction with proper conflict
detection:

// ✅ This is correct
export async function createBooking(input: CreateBookingInput) {
  const startDateTime = new Date(`${input.date}T${input.startTime}:00`)
  const endDateTime = new Date(
    startDateTime.getTime() + input.duration * 60 * 1000
  )

  return await db.transaction(async (tx) => {
    // Re-check availability INSIDE the transaction
    const conflict = await tx
      .select()
      .from(bookings)
      .where(
        and(
          eq(bookings.resourceId, input.resourceId),
          gte(bookings.endTime, startDateTime),
          lte(bookings.startTime, endDateTime),
          ne(bookings.status, 'cancelled')
        )
      )
      .limit(1)

    if (conflict.length > 0) {
      throw new Error('SLOT_NOT_AVAILABLE')
    }

    // Create booking inside the same transaction
    const [newBooking] = await db
      .insert(bookings)
      .values({
        tenantId: input.tenantId,
        resourceId: input.resourceId,
        serviceId: input.serviceId,
        customerName: input.customerName,
        customerEmail: input.customerEmail,
        startTime: startDateTime,
        endTime: endDateTime,
        status: 'confirmed',
        paymentStatus: 'unpaid',
      })
      .returning()

    return newBooking
  })
}

When two requests arrive simultaneously, PostgreSQL's transaction
isolation ensures only one succeeds. The other hits a conflict and
gets a clean error to surface to the user.

The overlap detection logic

The conflict query deserves a closer look. You need to catch
every possible overlap between the requested slot and existing
bookings:

and(
  eq(bookings.resourceId, input.resourceId),
  gte(bookings.endTime, startDateTime),   // existing booking ends after new one starts
  lte(bookings.startTime, endDateTime),   // existing booking starts before new one ends
  ne(bookings.status, 'cancelled')        // ignore cancelled bookings
)

The overlap condition endTime >= newStart AND startTime <= newEnd
catches all four overlap scenarios:

Scenario 1: New slot completely inside existing booking
  Existing: [====existing====]
  New:           [=new=]

Scenario 2: Existing booking completely inside new slot
  Existing:   [=existing=]
  New:      [======new======]

Scenario 3: New slot overlaps start of existing booking
  Existing:    [====existing====]
  New:    [====new====]

Scenario 4: New slot overlaps end of existing booking
  Existing: [====existing====]
  New:              [====new====]

All four are caught by the single condition above.

Handling the error in the API route

The transaction throws SLOT_NOT_AVAILABLE when a conflict
is detected. Catch it in your API route and return a clean
response to the client:

export async function POST(request: NextRequest) {
  try {
    const body = await request.json()
    const booking = await createBooking(body)
    return NextResponse.json({ booking }, { status: 201 })
  } catch (error) {
    if (error instanceof Error && 
        error.message === 'SLOT_NOT_AVAILABLE') {
      return NextResponse.json(
        { error: 'This slot is no longer available. Please choose another time.' },
        { status: 409 }
      )
    }
    return NextResponse.json(
      { error: 'Something went wrong' },
      { status: 500 }
    )
  }
}

HTTP 409 Conflict is the correct status code here —
the request was valid, but conflicted with the current
state of the resource.

The availability calculation layer

The transaction handles the write-side protection. But you
also need the read-side: showing users which slots are
actually available before they try to book.

export async function getAvailableSlots(
  resourceId: string,
  date: string,
  duration: number
): Promise<TimeSlot[]> {
  const dateObj = new Date(date + 'T00:00:00')
  const dayOfWeek = dateObj.getDay()

  // Get working hours for this resource on this day
  const workingHours = await db
    .select()
    .from(availability)
    .where(
      and(
        eq(availability.resourceId, resourceId),
        eq(availability.dayOfWeek, dayOfWeek),
        eq(availability.isActive, true)
      )
    )

  if (workingHours.length === 0) return []

  // Get existing bookings for this day
  const dayStart = new Date(date + 'T00:00:00')
  const dayEnd = new Date(date + 'T23:59:59')

  const existingBookings = await db
    .select({
      startTime: bookings.startTime,
      endTime: bookings.endTime,
    })
    .from(bookings)
    .where(
      and(
        eq(bookings.resourceId, resourceId),
        gte(bookings.startTime, dayStart),
        lte(bookings.startTime, dayEnd),
        ne(bookings.status, 'cancelled')
      )
    )

  // Generate available slots
  const availableSlots: TimeSlot[] = []

  for (const hours of workingHours) {
    const workStart = timeToMinutes(hours.startTime)
    const workEnd = timeToMinutes(hours.endTime)

    for (
      let slotStart = workStart;
      slotStart + duration <= workEnd;
      slotStart += duration
    ) {
      const slotEnd = slotStart + duration

      const isOccupied = existingBookings.some(booking => {
        const bookingStart =
          booking.startTime.getHours() * 60 +
          booking.startTime.getMinutes()
        const bookingEnd =
          booking.endTime.getHours() * 60 +
          booking.endTime.getMinutes()

        return slotStart < bookingEnd && slotEnd > bookingStart
      })

      if (!isOccupied) {
        availableSlots.push({
          startTime: minutesToTime(slotStart),
          endTime: minutesToTime(slotEnd),
        })
      }
    }
  }

  return availableSlots
}

Why not use pessimistic locking?

You might wonder why not lock the row with SELECT FOR UPDATE
instead of using a transaction with conflict detection.

Pessimistic locking works but has downsides:

Locks the row for the entire duration of the transaction
Under high load, requests queue up waiting for the lock
More complex to implement correctly across all edge cases

The conflict detection approach is optimistic — it assumes
most requests won't conflict, and only handles the rare case
where they do. This scales better and is simpler to reason about.

What I learned

The gap between check and insert is where bugs live.
Any code that reads state and then writes based on that
state has a potential race condition. The database transaction
is the only reliable way to close that gap.

Idempotency matters. If your client retries on failure,
make sure duplicate booking attempts are handled gracefully —
either by returning the existing booking or a clear conflict error.

Test with concurrent requests. Use a simple script to
fire 10 simultaneous POST requests for the same slot.
Only one should succeed. If more than one does, you have a bug.

This availability engine and race condition protection is
built into SlotKit — a production-ready booking SaaS
template for agencies. If you're building booking
functionality for clients, you don't have to solve this
from scratch every time.

→ slotkit.dev

Follow-up: The double-booking bug I shipped explains why a transaction alone isn't enough, and the lock-based fix that SlotKit now uses. Live demo · 20% off until November 8 with DEVTO20

Building automated booking reminders with Vercel Cron Jobs and Resend

SlotKit — Mon, 01 Jun 2026 15:00:19 +0000

Update (October 2026): SlotKit is now on Next.js 16 with a mobile-friendly dashboard, double-booking protection and per-tenant timezones. Live demo

Every agency developer knows this feeling.

One of the most requested features in any booking platform is simple:
"Send me a reminder before my appointment."

It sounds trivial. But when you start thinking about the infrastructure —
scheduled jobs, email queues, timezone handling — it gets complex fast.

Here's how I built automated booking reminders in Next.js 15 using
Vercel Cron Jobs and Resend, with zero additional infrastructure.

The problem with scheduled tasks in Next.js

Next.js is a request-driven framework. It handles HTTP requests — it doesn't
natively run background jobs on a schedule.

Traditional solutions involve:

A separate cron server (more infrastructure to manage)
A queue service like BullMQ or AWS SQS (overkill for most projects)
A third-party scheduler service (another paid dependency)

Vercel Cron Jobs solve this cleanly. They're available on all plans
including Hobby, configured in a single JSON file, and trigger your
existing API routes on a schedule.

Setting up Vercel Cron Jobs

Create a vercel.json in the root of your project:

{
  "crons": [
    {
      "path": "/api/cron/reminders",
      "schedule": "0 8 * * *"
    }
  ]
}

0 8 * * * runs every day at 8:00 AM UTC. That's it — no additional
setup, no dashboard configuration beyond deploying your app.

Securing the endpoint

Vercel sends requests to your cron endpoint from their infrastructure.
You need to verify these requests come from Vercel and not from a random
external caller.

The standard approach: a shared secret in an Authorization header.

export async function GET(request: NextRequest) {
  const authHeader = request.headers.get('authorization')

  if (authHeader !== `Bearer ${process.env.CRON_SECRET}`) {
    return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })
  }

  // proceed with the job
}

Set CRON_SECRET in your Vercel environment variables. Generate a
secure value with:

node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

Finding tomorrow's bookings

The reminder logic is straightforward: find all confirmed bookings
that start tomorrow, then send an email for each one.

const tomorrow = new Date()
tomorrow.setDate(tomorrow.getDate() + 1)
tomorrow.setHours(0, 0, 0, 0)

const tomorrowEnd = new Date(tomorrow)
tomorrowEnd.setHours(23, 59, 59, 999)

const upcomingBookings = await db
  .select()
  .from(bookings)
  .where(
    and(
      eq(bookings.status, 'confirmed'),
      gte(bookings.startTime, tomorrow),
      lte(bookings.startTime, tomorrowEnd)
    )
  )

Two things worth noting:

Only confirmed bookings. Pending bookings (waiting for payment
confirmation) are excluded. You don't want to remind someone about
an appointment that isn't actually confirmed yet.

Midnight boundaries. Setting setHours(0, 0, 0, 0) and
setHours(23, 59, 59, 999) ensures you capture the full day
regardless of what time the cron runs.

Sending the reminder email with Resend

For each booking, we fetch the related service, resource, and tenant
data, then send the reminder:

for (const booking of upcomingBookings) {
  try {
    const [service] = await db.select().from(services)
      .where(eq(services.id, booking.serviceId)).limit(1)

    const [resource] = await db.select().from(resources)
      .where(eq(resources.id, booking.resourceId)).limit(1)

    const [tenant] = await db.select().from(tenants)
      .where(eq(tenants.id, booking.tenantId)).limit(1)

    if (!service || !resource || !tenant) continue

    const html = await render(
      BookingReminderEmail({
        customerName: booking.customerName,
        businessName: tenant.name,
        serviceName: service.name,
        resourceName: resource.name,
        date: formatDate(booking.startTime),
        startTime: formatTime(booking.startTime),
        endTime: formatTime(booking.endTime),
      })
    )

    await resend.emails.send({
      from: process.env.RESEND_FROM_EMAIL!,
      to: booking.customerEmail,
      subject: `Reminder: your appointment tomorrow at ${tenant.name}`,
      html,
    })

    sent++
  } catch (error) {
    console.error(`Failed to send reminder for booking ${booking.id}:`, error)
    failed++
  }
}

return NextResponse.json({ success: true, sent, failed, total: upcomingBookings.length })

The try/catch per booking is intentional — if one email fails, the
loop continues and sends the remaining reminders. A single Resend
error shouldn't block everyone else's reminders.

The email template

Using React Email for the reminder template keeps things consistent
with the rest of the email system:

export function BookingReminderEmail({
  customerName,
  businessName,
  serviceName,
  resourceName,
  date,
  startTime,
  endTime,
}: BookingReminderEmailProps) {
  return (
    <Html>
      <Preview>Reminder: your appointment tomorrow at {businessName}</Preview>
      <Body>
        <Container>
          <Heading>Reminder: appointment tomorrow 🗓️</Heading>
          <Text>
            Hi {customerName}, this is a reminder for your appointment tomorrow.
          </Text>
          <Section>
            <Text><strong>Service:</strong> {serviceName}</Text>
            <Text><strong>With:</strong> {resourceName}</Text>
            <Text><strong>Date:</strong> {date}</Text>
            <Text><strong>Time:</strong> {startTime} – {endTime}</Text>
          </Section>
        </Container>
      </Body>
    </Html>
  )
}

Testing locally

Vercel Cron Jobs only trigger in production. For local development,
call the endpoint manually with the cron secret:

PowerShell:

$secret = (Get-Content .env.local | Select-String "CRON_SECRET").ToString().Split("=")[1]
Invoke-RestMethod -Uri "http://localhost:3000/api/cron/reminders" `
  -Headers @{Authorization="Bearer $secret"}

curl:

curl -H "Authorization: Bearer YOUR_CRON_SECRET" \
  http://localhost:3000/api/cron/reminders

The endpoint returns the count of sent and failed emails — useful
for verifying everything worked correctly.

What I learned

Vercel Cron Jobs are underrated. For most booking or scheduling
use cases, they're all you need. No queue infrastructure, no worker
processes, no additional cost.

Fail per item, not per batch. The try/catch inside the loop
pattern is important. A single failed email shouldn't abort the
entire reminder run.

Test with real data. Insert a booking with startTime = tomorrow
directly in your database and verify the email arrives before deploying.
Cron bugs are annoying to debug in production.

This reminder system is part of SlotKit — a production-ready
booking SaaS template for agencies built on Next.js 15, Supabase,
Stripe, and Resend.

If you're building booking functionality for clients and tired of
rebuilding the same infrastructure: slotkit.dev

Happy to answer questions in the comments.

Booking reminders like these are built into SlotKit, a Next.js multi-tenant booking template for agencies, with emails shown in each business's own timezone. Live demo · 20% off until November 8 with DEVTO20

How I stopped rebuilding the same booking logic for every agency client

SlotKit — Sat, 30 May 2026 17:45:28 +0000

Update (October 2026): SlotKit is now on Next.js 16 with a mobile-friendly dashboard, double-booking protection and per-tenant timezones. Live demo

Note: the race-condition section below is outdated — a transaction alone isn't enough. See The double-booking bug I shipped.

Every agency developer knows this feeling.

A new client comes in. They want a booking platform — a salon, a clinic, a gym,
a restaurant. Doesn't matter. And you think: "I've built this before."

Because you have. Three times last year. With different stacks, different
architectures, different levels of quality. Each time starting from scratch.

This is the story of how I decided to stop doing that.

The problem with booking systems

On the surface, booking looks simple. A customer picks a date, picks a time,
confirms. Done.

But the moment you go deeper, the complexity explodes:

Availability calculation. You need to know which time slots are free for
each resource (a staff member, a room, equipment). That means reading working
hours, existing bookings, and computing gaps — correctly, for every request.

Race conditions. Two customers book the same slot at the same millisecond.
Who gets it? Without proper handling, both. You now have a double booking.

Multi-tenancy. If you're an agency, you're not building for one client.
You're building the same infrastructure for ten clients. Each one needs isolated
data, separate working hours, separate services.

Payments. If the service has a price, you need Stripe, webhooks, and
payment confirmation before you confirm the booking.

Each of these is solvable. But solving all of them, correctly, every time,
for every client? That's 80-120 hours of plumbing that isn't billable as
innovation.

The architecture decision: row-level multi-tenancy

The first key decision was how to handle multi-tenancy.

Two common approaches:

Separate database per tenant — maximum isolation, but operationally complex and expensive
Shared database with tenant_id — simpler to operate, needs careful access control

I went with option 2, using a tenant_id column on every table and
enforcing isolation at the API layer.

// Every query is scoped to the current tenant
const tenantResources = await db
  .select()
  .from(resources)
  .where(eq(resources.tenantId, currentUser.tenantId))

The critical security rule: never trust tenantId from the request body.
Always derive it from the authenticated user's session. This prevents a
malicious actor from accessing another tenant's data by forging a request.

// ❌ Wrong — trusts client input
const { tenantId, resourceId } = body

// ✅ Correct — derives tenantId from the resource itself
const [resource] = await db
  .select({ tenantId: resources.tenantId })
  .from(resources)
  .where(eq(resources.id, resourceId))
  .limit(1)

The availability engine

The availability calculator is the heart of any booking system.

The logic:

Load working hours for the resource on the requested day
Load existing bookings for that day
Generate time slots of the requested duration
Filter out slots that overlap with existing bookings

function getAvailableSlots(
  workingHours: { startTime: string; endTime: string }[],
  existingBookings: { startTime: Date; endTime: Date }[],
  duration: number // minutes
): TimeSlot[] {
  const slots: TimeSlot[] = []

  for (const hours of workingHours) {
    let current = parseTime(hours.startTime)
    const end = parseTime(hours.endTime)

    while (addMinutes(current, duration) <= end) {
      const slotEnd = addMinutes(current, duration)

      const hasConflict = existingBookings.some(booking =>
        current < booking.endTime && slotEnd > booking.startTime
      )

      if (!hasConflict) {
        slots.push({ startTime: formatTime(current), endTime: formatTime(slotEnd) })
      }

      current = addMinutes(current, duration)
    }
  }

  return slots
}

Preventing race conditions

The availability check and the booking creation are two separate operations.
Between them, another user could book the same slot.

The solution: wrap the entire booking creation in a database transaction with
a conflict check.

await db.transaction(async (tx) => {
  // Check again inside the transaction
  const conflict = await tx
    .select()
    .from(bookings)
    .where(
      and(
        eq(bookings.resourceId, resourceId),
        lt(bookings.startTime, endDateTime),
        gt(bookings.endTime, startDateTime),
        ne(bookings.status, 'cancelled')
      )
    )
    .limit(1)

  if (conflict.length > 0) {
    throw new Error('SLOT_NOT_AVAILABLE')
  }

  // Safe to create
  await tx.insert(bookings).values({ ... })
})

If two requests arrive simultaneously, the database transaction ensures only
one succeeds. The other gets a clear error and the user is asked to choose
a different slot.

Stripe Checkout integration

For paid bookings, the flow is:

Customer fills in their details
We create a pending booking in the database
We create a Stripe Checkout Session with the booking ID in metadata
Customer redirects to Stripe, completes payment
Stripe fires a webhook
We confirm the booking and send the confirmation email

The key insight: send the confirmation email only after the webhook,
not when the booking is created. A pending booking is not a confirmed booking.

// In the webhook handler
if (event.type === 'checkout.session.completed') {
  const { bookingId } = event.data.object.metadata

  await db.update(bookings)
    .set({ status: 'confirmed', paymentStatus: 'paid' })
    .where(eq(bookings.id, bookingId))

  await sendConfirmationEmail({ bookingId })
}

The result: SlotKit

After building all of this, I packaged it into SlotKit — a production-ready
Next.js 15 booking SaaS template for agencies.

It includes everything described in this article, plus:

5 vertical presets (salon, clinic, fitness, professional, restaurant) — each with pre-seeded services, resources, and working hours
Admin dashboard for managing bookings, resources, and services
Multi-language support (EN/IT out of the box)
Security hardened: Zod validation, rate limiting, security headers

The idea is simple: an agency buys it once, deploys it for every client that
needs booking functionality. No more rebuilding the same plumbing.

If you're interested: slotkit.dev

What I learned

Building this taught me a few things worth sharing:

Database transactions are underused. Most developers check availability
and then create the booking in two separate queries. Wrapping them in a
transaction is the only correct way to prevent race conditions.

Never trust the client. Any identifier that controls data access should
be derived server-side, never taken from the request body.

Emails should reflect reality. Sending a "booking confirmed" email
before the payment clears creates trust problems. The webhook pattern solves
this cleanly.

Happy to answer any questions in the comments.

Try it: SlotKit is the template this article is about, now at v1.5 with tested payments, timezones and a mobile admin dashboard. Built for agencies serving clinics and medical practices: it's appointment booking, not a medical records system.

Live demo (login details are on the page) · 20% off until November 8 with DEVTO20