APIs & webhooks
Help with · APIs & webhooks

API Creates Duplicate Bookings? What to Check

Find why one booking request creates two appointments. Check repeat messages, retries and the record used to recognise a request that was already handled.

A person books one visit, but two appointments appear in the diary. The form might have sent twice. A webhook might have arrived again. Or your app might have retried a request after losing the reply. Start by finding out whether you have two copies of one request or two different requests for the same visit. The fix depends on that answer.

Things to check first

  1. Use a made-up booking in a separate test account. Compare the request ID, webhook event ID and appointment ID for each copy. Hide names, access keys and message contents in any notes you share.
  2. Check both the sender's delivery log and the receiver's run history. Did the same event arrive twice, or did one run create two appointments? A successful webhook reply does not prove the whole job finished.
  3. List every tool allowed to create bookings. A website form, an n8n workflow and a second app may all be reacting to the same action. Do not delete appointments until you know which ones are real.
Follow one requestOpen full-size image ↗
n8n example workflow with connected processing steps

One booking may pass through several steps. Check where each copy starts and which step writes the appointment. This is a general n8n example, not a tested clinic workflow.

Screenshot: n8n. Example screen; yours may look different.

What to ask the freelancer to do

  • Trace the repeated request and saved appointments
  • Add the supported repeat-request controls
  • Test simultaneous copies and a worker restart
  • Document recovery and linked record IDs

Questions to ask before hiring

  • Can you show a test with two copies arriving together?
  • What happens if the appointment saves but your worker stops?
  • How will two genuine visits for the same person stay separate?

Red flags

  • Uses the patient's name as the only duplicate check
  • Marks work complete before the booking is safely saved or queued
  • Deletes every matching appointment automatically

Agree what the job includes

  1. Follow one booking from the original request to the saved appointment. Keep the sender's reference and the destination's appointment ID linked. A customer email address alone is not a safe booking reference: the same person may book two visits.
  2. Agree how the app recognises a repeat request. Developers call this idempotency: repeating one request should not repeat the business action. If the vendor supports a request key, check its rules. Adding an unsupported header does nothing.
  3. Test two copies arriving at the same time. A simple 'look first, then create' check can still let both through. The developer must explain how only one worker wins, how failed work can resume and how a crash after saving is handled.

What to send the freelancer

  • Send a small diagram of the booking route and redacted examples of the repeated IDs. State whether the second appointment is identical or has different details.
  • List retries, queues and other workflows that write into the diary. Ask the clinic software supplier which tools can create or find appointments through its API.
  • Agree a test account, test contacts and cleanup steps. Keep patient data and real reminder messages out of the tests.

How to check the work is done

  • One request delivered twice creates one appointment. Two valid requests for different visits still create two appointments.
  • Two copies sent together and a retry after a worker restart do not create an extra appointment. A stopped job can be recovered without silently losing it.
  • The handover shows the linked IDs, how long repeat-request records are kept and what staff should do if a booking's result is unclear.

What may cost extra

  • Sorting out old duplicate appointments needs a separate plan and someone authorised to decide which bookings to keep.
  • A request key supported by one API is not a promise that every connected app supports it. Vendor changes and new booking channels need separate checks.
Sources checked 23 October 2026

Use this guide to agree the work and check the result.

Common questions

Why does a webhook arrive more than once?

Some senders retry when they do not receive a successful reply in time. Stripe, for example, documents repeat deliveries. Check your own sender's rules; a repeated message does not always mean a new booking.

Will turning off retries stop duplicate appointments?

It may hide one cause while allowing failed bookings to disappear. The better goal is to make repeats safe and give unfinished requests a clear recovery path.

More help: Source 1 · Source 2

Take the next step

Find help on Fiverr

Ready to hand it over? This freelancer offers help with the job covered in this guide. Look at their work and send them your brief to get a quote.

Luqman Khanzada

@luqman1122 · Fiverr

Node.js booking retry repair

For a Node.js integration, this listing covers API bug fixes and database work. Ask for a quote that includes safe repeat requests and two copies arriving together. Clinic API experience is not confirmed.

The listing showed 112 reviews when checked. Reviews cover a range of jobs; they do not prove experience with your clinic software.

Before you hire: Ask for a similar repair example, current availability and a test that sends two copies at the same time.

View service on Fiverr ↗

Listing checked 2026-10-23. We have not hired this freelancer or tested their work.

Your project

Build my freelancer brief

Answer a few questions to make a clear job description you can send to a freelancer.

Build my brief →

Other guides that may help

Browse APIs, integrations & data services →