Early access
Scheduling your users never have to leave your app for.
An embeddable booking engine for teams building on pxpn.dev. Calendar sync, timezone logic and metered billing are already solved — you render a component.
- OAuth tokens that quietly expire.
- DST bugs that only appear in March.
- An iframe you cannot style.
- No idea what to charge per booking.
The parts nobody wants to write twice
Scheduling is small until it is not. These are the pieces that turn a two-day feature into a quarter, and they arrive with the module.
Calendar sync
Two-way with Google and Outlook, including the unglamorous half: refresh handling, reconnect prompts, and a conflict check against the live calendar before anything is confirmed.
Timezone and availability
IANA-based and DST-safe, with buffers, lead time and rolling windows. The March bug is our problem, not the one you ship to your users.
Embed SDK
One script tag or a React component, themed to the host app. Real DOM you can style, not an iframe you have to negotiate with.
Metering and billing
Plans, limits, usage counting and overage arrive with the module rather than as the thing you bolt on after the first invoice is wrong.
The rest of the stack
Apple Calendar and CalDAV, Zoom and Google Meet links generated on confirm, and webhooks for everything your own system needs to hear about.
Your product, not ours
Your domain, your styling, your sending address. Nothing about booking a slot announces which engine is underneath it.
Three steps, then it is someone else's problem
Take an API key
One key per environment. Sandbox behaves exactly like production, including the calendar failures worth testing against.
Drop in the widget
A component or a script tag, pointed at a calendar and a duration. Style it with your own tokens; it inherits rather than imposes.
Bill for it
Bookings are counted as they happen and reported per customer, so charging for scheduling is a pricing decision rather than an engineering project.
We are building this now
pxBook.me is early. We are looking for a small number of teams who need scheduling inside their own product and would rather help shape the engine than write timezone math for the third time.
Tell us what you are building