Build a Base44 booking app that takes real bookings

Base44 gives every app its own database, so the obvious way to build a booking app there is to let it make an Appointment entity and a form that writes to it. That works until two customers pick the same slot, someone needs a refund, or the business wants the bookings in the same place as the ones coming in by phone.

The better split: Base44 builds the app, and Opencals runs the booking. Opencals already holds the services, staff, schedules and prices, works out availability, holds the slot during checkout, takes payment through the business's own Stripe account and sends the confirmation. The Base44 app calls it through a single backend function and renders what comes back.

This guide sets that up. You add one secret, two workspace skills that teach Base44's AI how Opencals works, and a first prompt.

What you need

• An Opencals store with at least one service and a schedule. Create one free. New stores are free development stores with Stripe in test mode, so you can build and test without paying anything.
• A Base44 Builder plan or higher. Backend functions and workspace skills both need it, and you need to be a workspace owner or admin to add skills.

Step 1: a storefront key without allowed origins

In the Opencals dashboard, open Settings → API Keys and create a storefront key. It starts with sfk_. Leave its allowed origins empty: the backend function calls Opencals from Base44's servers, which send no Origin header, and a key with an allowlist answers 401 Origin not allowed.

Step 2: add the two workspace skills

Skills are the reason this works. They're instructions Base44's AI reads whenever a prompt touches their subject, and they apply to every app in the workspace, so you only do this once.

Click your workspace name in the bottom left, then Settings, then Skills under Plugins, and Add skill. Choose Start from scratch and fill in the first one:

Loading…

Then add the second skill the same way:

Loading…

The first skill is the full endpoint reference, with rules like "the bookable ID is always a variant's id" and "slot times are UTC, convert them for display only". The second is written for Base44 specifically. Its first section defines the backend function everything goes through; the rest tells the AI to match the booking flow to the business (a salon books a person, a sports club books a court on a grid, a studio sells spots in a class) and ends with a checklist.

Step 3: store the key as a secret

Create the app, then in the editor open Dashboard → Secrets → Add Secret:

If you skip this, Base44 asks for the secret in the chat the first time the function needs it. Either way it's stored encrypted and read only by backend code.

Step 4: the function first, then the site

This prompt order saves a round of debugging. Get the proxy working and tested before any UI depends on it:

When it shows your store's name, describe the business:

No class list, no prices, no timetable in the prompt. They come from the store, so a new class added in the Opencals dashboard shows up without another prompt.

Why one function instead of Base44's custom integrations

Base44 also lets workspace admins import an API from its OpenAPI spec as a custom integration, and I looked at that first. The catch is the checkout. Opencals identifies a cart with an X-Cart-Id header on each request, and a signed-in customer with an Authorization header, and those change per visitor. A custom integration sends fixed headers set by the admin, so it can read the catalogue but can't run a cart through to payment.

A backend function has no such limit. It adds the key and version headers itself, passes each visitor's cart ID and token through, and returns the API's status and body untouched, so the UI can show the API's own error messages. It's a short function that Base44 writes from the playbook, and it allows only /storefront/ paths, so it can't be used to reach anything else.

Payments work the same way as on any Opencals site: checkout returns the Stripe details for the store's connected account, and the page renders Stripe's payment form. There's no Stripe secret in Base44.

Test a booking before you publish

1. The function test returns your store name and currency. A 404 Cannot GET means the X-Api-Version: 1 header is missing from the function.
2. The timetable or service list matches your Opencals dashboard; nothing is hard-coded or stored in entities.
3. Times show in the studio's timezone, not UTC.
4. Book, pay with Stripe's test card 4242 4242 4242 4242, and get a confirmation with an order number.
5. The booking appears in your Opencals dashboard with the confirmation email sent.

Then switch your Opencals store to production to take real payments, and publish the Base44 app.

Using another builder? There are matching guides for Lovable and v0, and the overview of all three is in build a booking website with AI.