Planned pricing

Pay once. Use credits when bookings are confirmed.

This is the commercial direction we are testing, published before it is built so nobody is surprised by it later. Nothing on this page is purchasable yet, and no prices have been set.

Slotkit is not currently billed. There is no checkout, no balance, no invoice, and no refund process. When this model is accepted and implemented, it will be announced with terms before anything is charged.

Why this is not a subscription

Slotkit is built to reach a sufficient feature set and then move to maintenance. It will be kept secure, current, and running. It is not on a path of permanent expansion, and we would rather say so than imply otherwise.

A monthly subscription sells continued development. A product that deliberately stops adding features cannot honestly sell that, and would spend the rest of its life defending a price against a roadmap it does not intend to have.

A prepaid booking sells something a maintenance-scoped product can keep promising indefinitely: that the booking will commit, reach the calendar, and deliver its webhook. That promise gets stronger as the system settles, not weaker.

One credit is one confirmed booking

The unit is a booking that actually happened, not a seat, a connected calendar, or a monthly platform tier. A Host who takes four bookings in a quiet month would use four credits.

Uses one credit

  • A booking that commits successfully and is confirmed to the guest
  • A booking made through the hosted page — same rule as the API
  • A booking made through the Public API — same rule as the hosted page
  • A confirmed booking whose calendar event is still being written

Uses no credit

  • Browsing available times and querying slots
  • Booking attempts that fail validation or lose the slot
  • CAPTCHA checks and guest email verification
  • An idempotent retry of a booking you already made
  • Rescheduling a booking that already exists
  • Calendar, Meet, and webhook retries behind a confirmed booking

The packs we are testing.

No pack size or price has been chosen.

Every workspace starts with free confirmed bookings

Granted once when the workspace is created, not refreshed monthly. Enough to finish guided setup and take real bookings before paying anything. It is counted on the server against your workspace, not in the browser.

How many has not been decided.

Starter

Price TBD

Individuals, consultants, and studios with irregular booking volume.

Good fit if: You want a booking page and would rather not pay a monthly fee for the months you barely use it.

Sized for about a year of one person taking a handful of bookings a week.

Team

Price TBD

Small teams with several Hosts and a steady weekly rhythm.

Good fit if: You need more than one Host, clear roles, and a cost that follows bookings instead of seats.

Sized to outlast a year for a few Hosts booking regularly.

Scale

Price TBD

Products booking through the Public API.

Good fit if: You are integrating scheduling into your own product and do not want a monthly platform fee to clear before your first booking.

Sized for a year or more at steady API volume.

Booking above the largest pack, or need an agreement, invoicing arrangements, or a support commitment? That is a conversation, not a fourth card.

Every pack includes the whole product

We are not planning to gate scheduling behavior behind a pack. Packs are expected to differ in how many confirmed bookings they include and what each one effectively costs — not in what the product does.

  • Hosted booking pages for every event type
  • Availability schedules, weekly rules, date overrides, and time blocks
  • Google Calendar and Google Meet per Host
  • Guest reschedule and cancellation links
  • Public API v1, TypeScript SDK, and scoped API keys
  • Signed webhooks with independent bounded retry
  • Owner, Admin, Member, and Host boundaries

How we propose credits should behave

These are proposals, not settled terms. They are here because a prepaid model where the rules arrive after the purchase is not a fair one.

Credits stay valid for 24 months
Any new purchase extends the whole remaining balance to 24 months from the most recent one, so a returning customer does not lose what they already paid for.
A cancellation does not return the credit
By the time a booking can be cancelled, the confirmed booking, its calendar event, its guest links, and its webhook have already been delivered.
A booking cancelled within ten minutes does
That covers duplicates and test bookings without opening a general refund path that a cancel-and-rebook loop could exploit.
Running out never costs you a real booking
Once a workspace has paid at least once, a small overdraft is allowed and settled on the next purchase. We would rather carry a balance than drop a booking a real person made.
Bookings you already have are never held back
Reschedule, cancellation, guest access, and webhook delivery keep working at a zero balance. Your guest should never be penalised for your balance.
Credits belong to one workspace
They are not transferable between workspaces. Transferable credits behave like a currency, and that is a far larger commitment than this product should make.

Still being decided

What is left after the proposals above. We would rather show these unanswered than answer them badly in a pricing table.

What a pack costs, and how many bookings it holds
No number has been validated against payment processing, support burden, cancellation behavior, breakage, or tax treatment. Publishing one early would be a guess wearing a price tag.
Whether prepaid credits may legally expire
Consumer voucher rules differ by country and some prohibit an expiry date outright. The 24-month proposal above survives only if legal review says it can.
How the free allowance should work
Whether a one-time grant is the right way in, how large it should be, and where the abuse boundary sits.
How refunds, taxes, and invoices work
Currencies, regional tax treatment, disputes, and whether unused credits survive workspace deletion or transfer.

If we ever stop running it

A product that plans to stop adding features owes you an answer to this question before you prepay anything, not after.

  • Unused credits are refunded in proportion to what is left.
  • Discontinuation is announced at least six months in advance.
  • The self-hosted production bundle stays available, and your data stays exportable.

These are proposed commitments. They bind us when they are published as terms, not before.

Slotkit is probably not the cheapest booking link

If all you want is a page where people pick a time, there are cheaper one-time offers and free tiers, and you should use one. We are not going to argue you out of that.

Slotkit is for when the booking has to become an event inside your own system: a versioned API, signed webhooks with bounded retry, and a reliability contract we publish and can be held to.

Want a say in this?

If prepaid booking credits would or would not work for how you schedule, tell us before it is built. We are collecting early-access interest by email — there is nothing to sign up for and nothing to pay.

Email us about early access