Building a barbershop voice agent on Retell — booking, upsells, FAQ all working. Stuck on Booksy: no public API, so I reverse-engineered their anonymous customer API. Shop/service/price data comes back fine with zero auth, but every availability/time-slot endpoint 404s (confirmed that’s “doesn’t exist,” not “gated” — /me returns 403 when auth is actually required). Also tried driving the public booking widget with headless browser — same wall, “Book” never fires an API call, page just shows a login prompt.
Looks like a logged-in Booksy consumer session is unavoidable for availability + booking, even though the catalog is public. Planning to run one service account that books on behalf of callers.
Questions:
Anyone done this — authenticated-session route, or is there an actual partner API I’m missing?
How do you keep that session alive for a function call that can fire mid-call without adding latency?
Any webhook/push option instead of polling availability?
Have not built against Booksy myself, so treat that half as informed guessing. The Retell half I am confident on.
1. There is a Booksy Public API. Docs sit at docs.booksy.com/v01.html but they return a 401, so access is gated and you have to ask. Get the shop owner to raise it with their Booksy rep, that carries more weight than a developer email. Two risks with the service account plan: every booking lands under one customer identity, which wrecks the shop’s reporting and reminders, and anonymous endpoints change without notice so it breaks mid-call in front of a real customer.
2. Do not authenticate inside the function call. Put a small service between Retell and Booksy (n8n, vercel, a worker, whatever) that holds the session, refreshes it on a schedule, and retries once on a 401. Retell then hits an endpoint that is already logged in. Bigger win: pull the next 7 days of slots at call start and pass them in as dynamic variables, so the agent offers times instantly and only calls live at the confirm step. Turn on Speak during execution to cover the gap. The docs list Name, Description, Endpoint URL, Speak during execution and Speak after execution, but no timeout setting, so keep it fast and return a fallback rather than hanging.
3. No webhook I know of. Cache a narrow window, refresh in the background, then do one live check at the moment of booking. Stale slots matter less when the confirm is real. Worth adding a fallback too: if the write fails, take it as a booking request and SMS the shop.
Happy to see the endpoint details if you want to share.