# API Integration: Social Login Mapping, Client Account Creation, and Booking History Access
**URL:** https://tech-support.simplybook.me/t/api-integration-social-login-mapping-client-account-creation-and-booking-history-access/2337
**Category:** API General
**Created:** [September 21, 2026, 7:17am UTC](https://tech-support.simplybook.me/t/api-integration-social-login-mapping-client-account-creation-and-booking-history-access/2337 "2026-09-21T07:17:22Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@MNPraseptyo](https://tech-support.simplybook.me/u/MNPraseptyo)
#### Post date: [September 21, 2026, 7:17am UTC](https://tech-support.simplybook.me/t/api-integration-social-login-mapping-client-account-creation-and-booking-history-access/2337/1 "2026-09-21T07:17:22Z")
Hi SimplyBook Support Team,
We are currently developing a custom website and integrating [SimplyBook.me](http://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](http://SimplyBook.me)?
2. **Client Login Creation:** Can [SimplyBook.me](http://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.
---
### Author:  [@mib](https://tech-support.simplybook.me/u/mib)
#### Post date: [September 21, 2026, 7:17am UTC](https://tech-support.simplybook.me/t/api-integration-social-login-mapping-client-account-creation-and-booking-history-access/2337/2 "2026-09-21T07:17:40Z")
---
### Author:  [@vetalkor](https://tech-support.simplybook.me/u/vetalkor)
#### Post date: [September 21, 2026, 8:54am UTC](https://tech-support.simplybook.me/t/api-integration-social-login-mapping-client-account-creation-and-booking-history-access/2337/3 "2026-09-21T08:54:52Z")
Hi **[MNPraseptyo](https://tech-support.simplybook.me/u/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:
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.