Add a real booking system to Lovable with the Opencals connector

Lovable is very good at the part of a booking site people look at. It's less good at the part that has to be correct, because with no backend to talk to it invents one: slots in a table, bookings as rows, no idea that two people just picked the same Tuesday 10:00.

Lovable's custom connectors fix that properly. A workspace admin registers an API once, attaches a couple of knowledge files telling Lovable how to use it, and every project in the workspace can connect to it without anyone pasting a key into code. This guide sets up Opencals that way. At the end, you describe a business and Lovable builds a site that reads your real services, shows live availability, holds the slot while the customer checks out, and takes payment through your own Stripe account.

It takes about ten minutes, and nearly all of it is copy and paste.

Before you start

• An Opencals store. Create one free and add at least one service with a schedule, so there's something to book. A new store is a free development store that runs payments in Stripe test mode, which is exactly what you want while building.
• Admin or owner rights in your Lovable workspace. Lovable only lets admins and owners create custom connectors. Everyone else in the workspace can use it once it exists.

Step 1: a storefront key without allowed origins

In the Opencals dashboard, go to Settings → API Keys and create a storefront key. Call it "Lovable" so you know where it's used. It starts with sfk_.

Leave the allowed origins list empty. Lovable calls the API from its own servers, and those requests carry no Origin header. A key with an origins allowlist rejects them with 401 Origin not allowed for this API key, which is the single most common setup mistake. That's safe here, because the key never reaches the browser.

Step 2: create the connector

In Lovable, open Connectors, click + and choose Custom connector. Fill in the details section:

Step 3: authentication and the test request

Choose Advanced as the authentication method. Opencals needs two headers on every request, and Advanced is the method that can hold both:

Don't skip the version header. Every storefront route answers 404 Cannot GET … without X-Api-Version: 1, including the test request, so a missing version looks like a broken URL rather than an auth problem.

Step 4: the two knowledge files

This is what turns Lovable from guessing into knowing. Knowledge files are Markdown that Lovable reads whenever it writes code against the connector. Click Add knowledge file twice and paste these. Each is under Lovable's 50,000-character limit.

Loading…

Loading…

Use the title as the file's Name and the line under it as its Description. The description is what Lovable reads to decide which file to open, so it's worth copying exactly.

The first file is the reference: every endpoint with its real fields, and rules like "the bookable ID is always a variant's id" and "slot times are UTC, convert for display only". The second is the part I'd have wanted on day one. It tells Lovable to match the page flow to the business before worrying about looks: a salon books a person, a padel club books a court on a grid, a yoga studio sells spots in a class. It also lists the checks to run before calling the site done.

Click Create. Opencals now appears in your workspace's connector catalogue.

Step 5: connect it and describe the business

Open the Opencals connector and choose Add connection. Paste your sfk_ key into the first field and 1 into the second. Pick who can use this connection (only you, specific people, or the whole workspace), and Lovable runs the test request. A green check means the key and version header are right.

Link the connection to a project, then describe the business rather than the booking system:

No service list, no prices, no opening hours: those come from your store. Add a service in the Opencals dashboard next week and it appears on the site without another prompt.

What Lovable builds, and one limit to know

With the knowledge files in place, Lovable writes a thin server function per operation (list services, get slots, book a slot, start checkout) that calls Opencals through the connector, and a frontend that only talks to those functions. Card payments use Stripe's payment form in the page with the details Opencals returns from checkout, so there's no Stripe connector and no Stripe secret to set up in Lovable. The money goes to the Stripe account connected to your Opencals store.

The limit: rate limits are shared across the whole site. Opencals limits each key per client IP to 120 requests a minute. Behind Lovable's gateway every visitor arrives from the same address, so one Lovable site gets roughly 120 requests a minute across all of its visitors. That's fine for a single business, and the playbook tells Lovable to cache the catalogue and load availability one day at a time for this reason. If you're planning a launch that sends a crowd to the site at once, get in touch before it goes out.

Test one booking before you share the link

Run this in the Lovable preview with your development store:

1. The services page shows your real services and prices, and nothing is hard-coded.
2. Days with no availability are disabled, and times show in your local timezone.
3. Book a slot, go to checkout, and pay with Stripe's test card 4242 4242 4242 4242.
4. The confirmation page shows an order number, and the booking appears in your Opencals dashboard with a confirmation email sent.
5. An invalid promo code shows a clear error, and a real one changes the total.

When those pass, switch the store to production in the Opencals dashboard to take real payments, publish the Lovable app, and point your domain at it.

Using a different builder? The same setup exists for v0 and Base44, and the overview of all three is in build a booking website with AI.