Welcome to Micali.online

User roles

Every person who interacts with Micali.online falls into one of these roles. Roles control what someone can see, edit, and approve.

What each role can do

Account

An account represents a company or organisation that owns the booking setup — the salon, the studio, the clinic. Each account has its own public subdomain (for example yourname.micali.online) where visitors land to make a booking.

An account holds all the pieces a visitor interacts with: the memberships they can buy, the services and procedures they can book, the events they can sign up for, and the forms they fill in along the way.

Events

An event is a time slot — or a series of time slots — that visitors can sign up for. Use events for classes, group sessions, workshops, performances and any other reservation that is tied to a fixed start time.

Template events vs. classic events

Events come in two flavours:

• Template event — a reusable blueprint. Templates are never shown to visitors; they exist so you can spin up many real events with the same settings (capacity, form, messages, etc.) without re-entering everything.
• Classic event — a real, bookable event. A classic event can be created from scratch or linked to a template, in which case it inherits the template’s configuration.

Key settings to know

• Capacity — how many visitors can join one slot, and whether each visitor can bring “friends” (extra entities). Set minimum and maximum participants.
• Signup deadline — the latest moment a visitor can book. If left empty, bookings stay open until the event starts.
• Auto-confirmation — whether reservations are accepted instantly or wait for admin approval.
• Allowed memberships — restrict who can book by limiting the event to specific memberships. If you leave this empty, anyone can book.
• Waiting list — when the event is full, new visitors can be placed on a waiting list and notified automatically when a slot opens up.
• Messages — pick which message templates are sent for booking confirmation, payment reminders, cancellations, attendance reminders, and waiting-list updates. Each event has its own slot for every purpose, so you can mix and match templates per event.

Services & procedures

Services are for one-to-one bookings where the visitor picks a time that works for them. Think of a hair salon, a private lesson, a consultation, or a treatment.

How services and procedures relate

• A service is the container — the offering as a whole (for example, “Hair Salon Downtown”). It has a name, description, location, address and timezone.
• A procedure is one specific thing you can book inside that service (for example, “Haircut — 30 minutes”, “Colouring — 90 minutes”). A service can have many procedures.
• Availability is the calendar of time windows when visitors can choose to book. You set these per service.

On the public page, a visitor first picks a service, then a procedure, then an open time slot — and finally fills in any required form.

Automated messages

Each procedure can be wired to four message templates — one for the moment a booking is created, one for confirmation, one for denial, and a reminder before the appointment. Choose the templates per procedure so different services can speak in different tones.

Memberships

A membership is a pre-paid plan that a visitor purchases — a punch card, a monthly subscription, a season pass. Use memberships to bill in advance and to control who is allowed to book certain events.

What a membership defines

• Price & currency — what the visitor pays.
• Usage limits — maximum number of uses and/or maximum duration in days.
• Availability window — when the membership can be purchased (available_from and optional available_to).

How memberships gate events

By itself, a membership is just a product visitors can buy. To use it as a gate, link it to one or more events as an allowed membership. After that, only visitors holding that membership can book the event.

If a visitor with a valid membership does not show up, the event can be configured to still consume a credit from their membership.

Automated membership messages

Memberships can trigger four message templates:

• After each usage — confirm that a credit was spent and how many remain.
• Before the end date — a heads-up a configurable number of days before the membership expires.
• On expiry — sent when the membership ends.
• Low remaining uses — sent when the visitor’s remaining credits drop below a threshold you set.

Message templates

A message template is a reusable piece of text that the platform sends to visitors at the right moment — booking confirmation, payment reminder, attendance reminder, expiry warning, and so on. Define a template once at the account level and reference it from every event, service procedure or membership that should use it.

One template, two channels

Each template has slots for both an email version (subject + body) and an SMS version (subject + body). You can fill in one or the other, or both — at least one body must be present when you save.

What you leave blank is simply not used:

• If the email body is empty, no email is sent when this template is triggered.
• If the SMS body is empty, no SMS is sent when this template is triggered.

On an event, two account-level switches — send email and send SMS — decide which channels are dispatched for that event’s templates. Memberships expose the same pair of switches for the after-usage message. Other template slots simply send whichever channels the template itself has filled in.

Placeholders you can use

Templates support simple variables that get replaced with real data at send time. You can put any of these inside subject or body, on either channel:

Placeholders that don’t apply to a particular message (for example, %event_name% in a service reminder) are simply left empty.

Where templates are used

Templates aren’t sent on their own — they are picked up from the entity that triggers the message. Here is the full list of slots.

On an event

• Booking created — sent the moment a visitor submits a reservation.
• Confirmation — sent when the reservation is confirmed (manually or automatically).
• Payment missing — payment reminder, with one or two configurable lead times (first and second reminder, in hours before the event).
• Attendance reminder — sent a configurable number of hours before the event.
• Cancellation — sent when the visitor cancels.
• Account cancellation — sent when an admin cancels the visitor’s reservation.
• Waiting list — added — sent when the visitor is placed on the waiting list.
• Waiting list — promoted — sent when a slot opens up and the visitor is allowed to book.

On a service procedure

• Booking created — sent when the visitor submits the request.
• Confirmation — sent when the appointment is approved.
• Denial — sent when the request is rejected.
• Reminder — sent before the appointment.

On a membership

• After each usage — sent every time a credit is spent.
• Before end date — sent a configurable number of days before the membership expires.
• On expiry — sent when the membership reaches its end date.
• Low remaining uses — sent when the number of remaining credits falls below the threshold you set.

Public vs. Active — what each flag means

Events, services and memberships share two on/off switches. They look similar but they answer two different questions.

Combinations and what they mean

Webhooks

Webhooks let Micali.online notify your own systems the moment something happens inside an account — a new visitor, a booking, a membership payment. Configure one or more listener URLs per account, pick the events you care about, and Micali.online posts a JSON payload to each URL whenever they fire. Perfect for syncing bookings into a CRM, triggering downstream automations, or building dashboards on top of your reservation data.

Who can configure them

Only root admins can create, edit and delete webhook listeners. Admins and team members cannot see or change them. Webhooks live alongside the other integrations — open Connectors → Webhooks to manage them.

Events you can listen to

Each listener is bound to a single event type. Add several listeners — even pointing at the same URL — to receive more than one event type. The catalog of currently emitted events is:

• visitor.created — a new visitor signed up in the account.
• visitor.updated — an existing visitor profile was updated.
• event_booking.created — a visitor booked an event slot.
• event_booking.confirmed — an event booking was confirmed (manually or automatically).
• event_booking.cancelled — an event booking was cancelled.
• service_booking.created — a visitor booked a service slot.
• service_booking.confirmed — a service booking was confirmed.
• service_booking.cancelled — a service booking was cancelled.
• membership.assigned — a membership was assigned to a visitor.
• membership.paid — a visitor membership was marked as paid.
• membership.ended — a visitor membership reached its end date.

What gets sent

Each delivery is a single HTTP POST to your URL with a JSON body. The following headers always accompany the request:

• Content-Type: application/json — the body is always JSON-encoded.
• User-Agent: micali-webhooks/1.0 — identifies the sender.
• X-Micali-Event: <event_type> — repeats the event type so you can route without parsing the body.
• Authorization — present only when you configure authentication on the listener (see below).

Payload shape

All payloads share the same envelope:

• event — the event type (same value as the X-Micali-Event header).
• occurred_at — ISO-8601 timestamp of when the trigger ran.
• resource — the kind of object inside data: event_booking, service_booking or visitor_membership.
• data — a snapshot of the resource, including its public ID, current status flags, and the visitor’s contact details (email, first and last name, phone). Event and service bookings also include the linked event or service/procedure block; membership payloads include the membership name and public ID.

Identify objects across deliveries by their public_id — that’s the stable, human-shareable identifier we use everywhere else in the platform.

Authentication

Pick an authentication scheme so your receiver can verify the request originated from Micali.online:

• None — no Authorization header is sent. Use only when your endpoint is otherwise protected (signed URL, IP allow-list, private network).
• Basic — username and password are sent as the standard Authorization: Basic ... header.
• Bearer token — the token you provide is sent as Authorization: Bearer <token>. Stored encrypted at rest and never returned by the API once saved.

Delivery and retries

Delivery is asynchronous and runs through the platform’s background job queue. If the receiver returns a non-2xx status (or the request fails outright), the job retries with exponential backoff — starting at 60 seconds, doubling each time, and capped at one hour between attempts. After ten failed attempts the delivery is marked as failed and dropped. Listeners that are disabled or deleted between the trigger and the actual delivery are silently skipped.

How to create an event and publish it

For root admins and admins. The goal: a visitor can land on your public page and book a slot.

1. Open the Events page.

   Sign in to the app, choose the right account in the top bar, and open Events from the main menu.

2. (Optional) Create a template first.

   If you’re going to run the same kind of event repeatedly, create it once as a template — capacity, form, messages and so on. New classic events can then inherit from it.

3. Create a new classic event.

   Click New event, give it a name and description, set capacity (max participants, whether they can bring friends) and pick the booking form.

4. Add one or more event dates.

   For each occurrence set the start time and, if needed, the signup deadline. Without at least one upcoming date the event cannot be booked.

5. Restrict to memberships (optional).

   If only members can attend, add the required memberships under Allowed memberships. Leave empty to let any visitor book.

6. Pick the messages.

   Choose templates for payment reminders, cancellations and the attendance reminder. Make sure the matching connector (SMTP, SendGrid or Twilio) is configured at the account level.

7. Turn on Active.

   This makes the event live inside the account. It still won’t reach visitors until the next step.

8. Turn on Public.

   Now the event appears on your public subdomain. Open the subdomain in a private browser window to verify everything looks right.

How to create a service or procedure and publish it

For root admins and admins. The goal: a visitor can choose a procedure and book a free time slot.

1. Open the Services page.

   From the app menu, choose Services. The list shows everything that belongs to the active account.

2. Create the service.

   Click New service, enter the name, description, location, address and timezone. The timezone is important — all availability windows are interpreted in it.

3. Add procedures.

   For each thing a visitor can book, create a procedure with a name and duration. Optionally set preparation time before the procedure and clean-up time after it so the calendar doesn’t double-book.

4. Set availability.

   Define the recurring time windows when bookings are allowed (for example, Mon–Fri 9:00–17:00). Only slots inside an active availability window can be booked.

5. Pick the booking form (optional).

   If you need information from the visitor at booking time — phone, allergies, notes — attach a form to the service.

6. Turn on Active on the service and on each procedure.

   An inactive service hides everywhere; an inactive procedure stays in the database but doesn’t appear in the booking flow.

7. Turn on Public on the service.

   Visitors now see the service on your public subdomain, with the available procedures and the next open slots.

How to create a membership and publish it

For root admins and admins. The goal: a visitor can buy a membership and use it to book events.

1. Open the Memberships page.

   From the app menu, choose Memberships.

2. Create the membership.

   Click New membership, give it a name and a short description that explains what the visitor gets.

3. Set price, currency and limits.

   Enter the price (in the smallest currency unit), the currency, the maximum number of uses and/or the duration in days. Leaving a limit empty means it is unlimited.

4. Define when it can be purchased.

   Set available from (when it appears on the public page) and optionally available to (when it disappears). Useful for seasonal or limited-time offers.

5. (Optional) Link it to events.

   If the membership should unlock specific events, open each event and add the membership under Allowed memberships.

6. Turn on Active.

   The membership is now part of your account. Existing memberships of returning visitors keep working even when this is off.

7. Turn on Public.

   Visitors see the membership on your public subdomain and can purchase it. Confirm by opening the subdomain in a private window.

How to create a message template

For root admins and admins. Templates live at the account level — write them once and reuse them on any event, service or membership.

1. Open the Message templates page.

   From the app menu, choose Message templates inside the active account.

2. (Optional) Seed the defaults.

   If this is a fresh account, click Seed defaults to create a starter template for every supported slot in the account’s language. You can edit any of them afterwards.

3. Create a new template.

   Click New template and give it a clear, internal name — for example, “Yoga class — payment reminder”. The name is only shown to your staff.

4. Write the email version.

   Fill in the email subject and email body. Use placeholders like %visitor_first_name% and %event_start_at% wherever you want personalised values. Optionally set a sender name.

5. Write the SMS version (optional).

   If you also plan to send this as SMS, fill in the SMS body. Keep it short — SMS providers charge per segment.

6. Save the template.

   You need at least the name plus an email body or SMS body. The template now appears in the dropdowns on every event, procedure and membership form.

7. Attach the template where you need it.

   Open the relevant event, service procedure or membership and pick the new template in the appropriate slot — for example, Attendance reminder on an event. Save and you’re done.