API Integration: Social Login Mapping, Client Account Creation, and Booking History Access

API General
1

Hi SimplyBook Support Team,

​We are currently developing a custom website and integrating SimplyBook.me as our booking engine. We plan to allow users to sign in using social logins (Google and Facebook) on our platform, and we have a few questions regarding client management and authentication via the API:

  1. ​User Mapping: After a user successfully authenticates via Google or Facebook on our frontend, what is the recommended flow to associate that user with a Client profile in SimplyBook.me?
  2. ​Client Login Creation: Can SimplyBook.me Client Logins (client accounts) be created, linked, or managed programmatically via the API?
  3. ​Booking & History via Client ID: If we look up or create a Client using their email address and obtain their client_id, can that ID be directly used to create bookings and retrieve that specific user’s booking history?
  4. ​Client-Level Authentication: Is there a dedicated API endpoint, session mechanism, or client-level token for authenticating a user so they can securely access their own booking history?

​Thank you for your assistance, and we look forward to your guidance.

3

Hi MNPraseptyo,

Good questions — here’s how I’d approach this. Short version: you have two viable architectures here, and which one fits depends on how much you want SimplyBook itself to enforce client-level access vs. handling that in your own backend.

  1. Mapping social-login users to SimplyBook clients
    SimplyBook has no concept of “social login” — it doesn’t know anything about Google or Facebook. So the mapping has to live entirely on your side: when a user signs in via Google/Facebook, take whatever identifier comes back from that social login (typically their email, or the provider’s user ID), look up or create a matching client in SimplyBook, and then store that client’s client_id in your own database against your user record. From that point on, every time this user logs in through social login, you just look up their client_id from your DB instead of going through SimplyBook again — SimplyBook is only involved when you actually need to create/fetch bookings for them.

  2. Can client logins be created/managed via API?
    Two ways to do this, matching the two approaches above:

    • Admin API route: POST /admin/clients creates a client record outright, no password needed — fine if you’re staying entirely on the Admin API for bookings too.

    • Public API route: call POST /public/clients/register directly with the client’s email, name, and a random unique password you generate yourself (the user never sees or types it — it’s purely a backend-held credential). This creates the client through the Public API itself and immediately returns a PublicTokenEntity, so you get client creation and a client-scoped session token in one call, ready to use for /public/booking right away.

    Either creates the client; the Public API route is more convenient if you’re planning to use the Public API for bookings anyway (step 3), since it skips the separate /public/clients/login call right after creation.

  3. Can that client_id be used for bookings and booking history?
    Depends on which approach you pick:

  • Admin API route: pass client_id into POST /admin/bookings to create a booking on that client’s behalf, and use GET /admin/bookings?client_id= for their history. Your backend does everything and just relays results to the frontend.
  • Public API route: using the generated password from step 2, have your backend call POST /public/clients/login with the client’s email + that password to get a client-scoped PublicTokenEntity. With that token, GET /public/booking and POST /public/booking/item work directly and are inherently scoped to that one client.

Either works; the Public API route is arguably cleaner here since the API itself enforces the scoping instead of you having to enforce it yourself.

  1. Dedicated auth/security for client-level access?
    This is really the deciding factor between the two approaches above:
  • With the Admin API, the token (X-Company-Login + X-Token) is company-scoped — it can see/act on any client’s data. There’s no client-level security boundary at all, so your backend must itself verify that the logged-in user owns the client_id before returning any booking data, and this token must never reach the frontend.
  • With the Public API + generated password approach, the client-scoped token from /public/clients/login naturally restricts GET /public/booking etc. to that one client — the API does the isolation for you. The tradeoff is you’re managing a hidden password per client and doing an extra login call per session, but you get real per-client scoping instead of relying purely on your own backend checks.

A few important caveats before you build this:

  • Protect your Admin API credentials carefully. The company login + API key (or token) give full account access across all clients and bookings. Never ship them to the frontend, log them in plaintext, or commit them to a repo — treat them like any other production secret, with restricted access and rotation if they’re ever exposed.
  • Don’t store the generated client passwords in plaintext. If you go the Public API route, encrypt those credentials at rest (or store them in a secrets manager) rather than as plain text in your database — a database leak would otherwise expose login access to every client account you’ve created.
  • Be aware the two APIs offer different levels of freedom. The Public/client-level API applies more restrictions to what a booking can do (it’s designed for a client acting on their own behalf), while the Admin API gives you much more power — but with that power comes responsibility: since the Admin API won’t stop you from creating invalid or conflicting bookings the way client-level restrictions would, your backend needs to do its own validation (availability, business rules, etc.) before calling POST /admin/bookings.