TL;DR:<\/strong><\/p>\n Strip away the marketing language and a booking API is a handful of endpoints doing predictable jobs. Know what you are calling and why before you wire anything together.<\/p>\n Miss one and you get a booking flow that looks fine in a demo but falls over the moment stock, schedules or payment status disagree with the calendar.<\/p>\n Altegio splits these jobs across separate APIs. The Online Booking API has public endpoints for booking widgets and client portals and needs no user login. The Business Management API covers scheduling, clients, inventory, finances and loyalty: version 2 is recommended for new integrations, and version 1 is maintained for backward compatibility. Developer Tools holds webhooks, VoIP integration, reference dictionaries and the methods for apps published in the Integrations Hub. All requests are encrypted with TLS 1.2 or higher.<\/p>\n Before you plan endpoints, be clear about the credentials, because they decide whose data an integration can see.<\/p>\n Treat the access key as a secret and keep it out of front-end code and public repositories. Give the integration its own user and tick only the rights it needs when you set up the app: an app\u2019s system user has access rights much like a regular user, with some restrictions in the client base and user management. For testing, the documentation describes installing a draft app on a Location you control and making authenticated calls there before moderation, rather than a separate sandbox. Integrations built for other companies are reviewed before they appear in the Integrations Hub.<\/p>\n Most teams face this decision early, and it is worth settling before a single line of code gets written.<\/p>\n The common trap is budgeting for the build and forgetting the upkeep. A widget is configured once, while a bespoke flow has to be tested, monitored and updated whenever an API version or a business rule changes, and that work keeps going long after launch.<\/p>\n For most appointment-based businesses, the standard widget handles public booking and a few API hooks cover the parts that need custom logic, such as a stock check across Locations or a loyalty rule your platform doesn\u2019t cover.<\/p>\n In Altegio, online booking<\/a> comes with the platform. The same Appointment Calendar also takes appointments from Reserve with Google, which is free and connected under Integrations > Client acquisition > Google Maps, and from the Book now button on Instagram and Facebook, connected through an app in the Integrations Hub. Each extra channel feeds the same calendar, so it doesn\u2019t add another copy of your availability to keep in sync.<\/p>\n Two systems both think they hold the last free slot at 15:00. One of them is wrong, and if your architecture can\u2019t handle that, you get a double booking and an unhappy client at reception.<\/p>\n Shared equipment is a common blind spot. In Altegio, rooms, chairs and devices can be set up as Resources and linked to services. When a service with a Resource is booked, the Resource is reserved automatically, and an online appointment takes one free instance of each Resource, so two clients can\u2019t book the only massage room for the same time.<\/p>\n For webhooks, Altegio sends notifications to the address you set under Settings > Integrations and access > Webhooks, for the events you choose: changes to Location settings, team members, products, services, service categories, clients, appointments in the Appointment Calendar, and inventory and financial operations. Each notification is a POST request with a JSON body that describes the change, including the object type and a link to the changed object. Webhooks don\u2019t carry a traffic source or click ID, so they tell you what changed, not where a client came from.<\/p>\n A booking integration needs to fail predictably, because it will fail sometimes: a payment provider times out, a webhook is delayed, a network blip drops a request halfway through. What matters is what happens next.<\/p>\n Return clear, structured error codes rather than a generic failure message, so the calling system knows whether to retry, alert a human or roll back a partial booking. A 409 conflict for a slot that has just been taken is a different problem from a 500 error on your own server, and the client application should treat them differently.<\/p>\n Retries for transient failures should be automatic but bounded: exponential backoff with a sensible cap stops a struggling downstream service from being hammered by a queue of retries. Idempotency keys make retries safe in the first place, since a retried request with the same key should never create a second appointment. Pair that with a durable queue, so a failed delivery is retried later rather than lost, and a reconciliation job that finds bookings stuck in a pending state and resolves them one way or the other.<\/p>\n On the receiving side, design around how Altegio delivers webhooks:<\/p>\n Booking traffic is spiky. An integration can sit quiet for hours, then take a burst of requests when a promotion goes out or a popular slot opens. Design for the spike, not the average.<\/p>\n Altegio\u2019s API allows 200 requests per minute or 5 requests per second per IP address, so plan calls around that limit rather than around your peak demand. Cache availability queries, since a calendar check doesn\u2019t need a live call every time, but invalidate the cache as soon as a webhook says a slot has changed. Batch background syncs, spread them out and back off when you reach the limit, so public booking never waits behind a nightly export.<\/p>\n For multi-location businesses, partition work by Location so a busy branch doesn\u2019t slow down the others. Monitor latency per endpoint rather than as a single average, because a slow payment step hidden inside a fast overall response time only shows up once a client is already annoyed.<\/p>\n Before any calendar talks to any client database, get the legal groundwork right. The GDPR (Regulation 2016\/679) treats data concerning health as a special category: personal data about a person\u2019s physical or mental health that reveals information about their health status. Treatment notes, allergy flags and contraindications in a client card fit that description, and even an appointment for a specific treatment can reveal something about health.<\/p>\n A written processor contract under Article 28 is a legal requirement, not a nice-to-have.<\/strong> Every vendor that handles client or appointment data on your behalf needs one, and it is far easier to sign before the first API call than to explain its absence later.<\/p>\n Check what your booking flow collects, too. Altegio\u2019s booking widget has a mandatory checkbox for consent to personal data processing but no separate marketing-consent checkbox, so collect marketing consent another way if you need it. For visitors from the EU, the booking form blocks analytics and advertising cookies until the visitor consents.<\/p>\n PSD2 (Directive 2015\/2366) governs payment services, not bookings, so it only matters where your booking flow takes money.<\/p>\n In Altegio, online payments go through a connected provider \u2013 Stripe, or Adyen in EU countries \u2013 and Altegio charges no commission of its own on them. Payment policies<\/a> let you take a deposit with any provider available in your region, while a card guarantee works only with Adyen<\/a> in EU countries. If you are weighing bank payments, read Pay by bank in Europe: open banking for appointment businesses<\/a>.<\/p>\n Not every integration needs code any more. Altegio runs on the Model Context Protocol (MCP), so Claude, ChatGPT, Cursor or Gemini can work with a business account directly. The MCP and agentic management<\/a> page lists the connections:<\/p>\n An AI assistant connects without an access key: you add the MCP address to the assistant, sign in with your Altegio account and authorise access to the relevant Location. The data rules still apply. The assistant works with the same calendar, so it sees the same free slots, but it processes the data needed for each request under its AI provider\u2019s own terms, so review those data controls and connect only the access your team needs.<\/p>\n Before you write a line of integration code, lock down the business and legal decisions. Retrofitting compliance after launch costs far more than building it in from the start.<\/p>\n Treat the processor contract and data location questions as blocking tasks, not paperwork for after launch. A missing contract found six months in costs far more than one agreed before the first API call.<\/p>\n Building all of this from scratch is a serious project, which is why many businesses choose an integrated platform and use the API only for what is left. Altegio is built for appointment-based businesses \u2013 beauty, wellness, clinics, auto services, fitness and more \u2013 and keeps online booking, the Appointment Calendar, the client base, payments, inventory, payroll and finances in one system. Appointments from the widget, Reserve with Google, the Instagram and Facebook Book now button and the Altegio.me client app land in the same Appointment Calendar, so there is one version of your availability rather than several that disagree.<\/p>\n Back-office data stays connected as well. For example, inventory control<\/a> writes off consumables automatically through bills of materials linked to services, so stock moves with the appointments instead of through a separate sync.<\/p>\n It also shortens the compliance list. Every separate tool that touches client data is another processor to vet, another contract to sign and another place where data may leave the EEA. Fewer moving parts means fewer of those checks, though you still need to do them for every vendor you keep.<\/p>\n Most guidance on open API booking spends its energy on the technical build and treats compliance as a box to tick near the end. That ordering is backwards. The businesses that get into trouble are rarely the ones with clumsy webhook retries. They are the ones that connected a booking system to a client database without a processor contract or without noticing that treatment notes count as health data.<\/p>\n The usual advice to \u201cpick an API and start building\u201d skips the part that decides whether the integration survives an audit. Settle processor contracts, data locations and consent flows first. The engineering patterns \u2013 webhooks, idempotency, locking \u2013 are important, but they are well understood and are not where most businesses come unstuck. Prioritise the paperwork before the pull request: a technically elegant integration built on the wrong legal foundation is still the wrong integration.<\/p>\n If you want the booking widget, the API and the back-office modules already working together instead of building that yourself, here is where to start.<\/p>\n It means an API that exposes calendar, client, payment and back-office data, so a booking system can connect to other software without manual re-entry. For salons, spas and clinics that usually covers availability checks, appointment confirmations, client contact details and treatment data, and payment status.<\/p>\n A widget gets online booking live quickly and suits most single-location businesses, while a bespoke API integration gives full control but needs ongoing development time to maintain. Many businesses use the widget for public booking and add specific API hooks only for flows that need custom logic.<\/p>\n Yes, for every vendor that processes client or appointment data on your behalf. Article 28(3) of the GDPR requires a contract that sets out the subject matter, duration, nature and purpose of the processing and the processor\u2019s obligations, and Article 28(9) requires it in writing, including electronic form.<\/p>\n Reliable systems hold a slot with server-side locking or a short-lived reservation before confirming it, and make writes idempotent so a retried request can\u2019t create a duplicate. On the webhook side, deduplicating events and re-reading the current state of an appointment stops a repeated or late notification from overwriting newer data. Testing concurrent booking attempts on purpose is the standard way to catch race conditions before clients do.<\/p>\n Yes. There is a public Online Booking API, a Business Management API in versions 1 and 2, and Developer Tools with webhooks. Requests to Location data carry an access key from the free Developer Hub, passed as a Bearer token, and a user key for the Altegio user the integration acts as. AI assistants connect through Altegio\u2019s MCP servers by signing in with an Altegio account, with no key.<\/p>\n The API allows 200 requests per minute or 5 requests per second per IP address. Cache availability reads, batch background syncs and use webhooks instead of polling to stay within it.<\/p>\n This article is general information, not legal or tax advice. Rules differ between EU countries, so check your national law or ask a lawyer before acting.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Stop double bookings when you connect a booking API: slot holds, webhooks, retries and rate limits, plus the GDPR and PSD2 checks to do before go-live.<\/p>\n","protected":false},"author":34,"featured_media":49619,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"footnotes":"","_members_access_role":[],"_members_access_error":""},"categories":[319,346],"tags":[193,286],"class_list":["post-49646","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-protecao-de-dados","category-gestao","tag-booking-software","tag-online-booking"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n
\nWhat an open booking API actually exposes<\/h2>\n
\n
How authentication and testing work in the Altegio API<\/h2>\n
\n
Authorization: Bearer <partner_token>, User <user_token><\/code>.<\/li>\n<\/ul>\nWidget vs bespoke API: which route fits your build?<\/h2>\n
\n
Technical patterns that keep bookings consistent<\/h2>\n
\n
Handling error responses and retries in booking APIs<\/h2>\n
![\"Retry-safe](\"https:\/\/alteg.io\/blog\/wp-content\/uploads\/2026\/10\/open-api-booking-01.jpeg\")
<\/p>\n\n
Strategies for scalability and performance in booking APIs<\/h2>\n
GDPR checklist before you connect anything<\/h2>\n
\n
Where PSD2 comes in<\/h2>\n
\n
AI agents and MCP: a new kind of integration<\/h2>\n
\n
Developer and product-owner implementation checklist<\/h2>\n
\n
How an integrated platform reduces the risk and effort<\/h2>\n
Why the compliance work matters more than the code<\/h2>\n
![\"Illustration](\"https:\/\/alteg.io\/blog\/wp-content\/uploads\/2026\/10\/open-api-booking-02.jpeg\")
<\/p>\nNext steps with Altegio<\/h2>\n
\n
FAQ<\/h2>\n
What does \u201copen API booking\u201d mean for a salon or clinic?<\/h3>\n
Is a widget or a bespoke API integration better for a small business?<\/h3>\n
Do I need a data processing agreement to use a booking API?<\/h3>\n
How do booking APIs prevent double bookings?<\/h3>\n
Does Altegio offer an open API alongside its booking widget?<\/h3>\n
What are the Altegio API rate limits?<\/h3>\n
Read next<\/h2>\n
\n