For developers
Partner API
If a center already runs its own booking/appointment system on its own website or app, it doesn't have to give that up to be discoverable and bookable on youShine. The Partner API keeps that system in sync with bookings made through youShine, in whichever of two ways fits it best.
Overview
youShine remains the center's full booking engine as normal — its own service catalog, its own availability, customers still book through the youShine app and website. The Partner API adds one thing on top: a way for the center's own system to find out about bookings that came in through youShine, so its own staff-facing calendar stays accurate too.
Pull
Your system polls youShine with an API key on whatever schedule suits you. No inbound connection from youShine to you is required.
Push
youShine POSTs a signed event to an endpoint you host as soon as a booking is created, cancelled, or rescheduled — near real-time, no polling.
Both are optional, both can be on at once, and neither requires migrating any existing data out of your system — youShine only ever tells you about bookings it made itself.
Getting started
A center owner generates credentials from the center-portal dashboard, under Settings → Partner API — no request to youShine needed. Generating a pull key is the first step either way; webhook delivery is an add-on you can turn on afterward from the same page.
Authentication
The pull feed and webhook delivery use two different, independent credentials — enabling one doesn't require or affect the other.
Pull feed: send your API key as a bearer token on every request.
Authorization: Bearer sk_partner_live_...Webhook delivery: every delivery is signed with your webhook secret so you can verify it genuinely came from youShine. Compute an HMAC-SHA256 of the raw request body using your secret and compare it, byte for byte, against the header:
X-Partner-Signature: sha256=<hex-encoded HMAC>Rotating either credential from center-portal invalidates the old one immediately — the new value is shown exactly once, at the moment you generate or rotate it. youShine never stores either in a form it could show you again later.
Pulling bookings
GET /partner/v1/bookings?since=<ISO 8601 timestamp> returns bookings created or changed since the given cursor, oldest first, capped at 100 per call. Omit since on your very first call to get everything so far.
{
"items": [
{
"id": "b1a2c3d4-...",
"startsAt": "2026-09-04T10:00:00.000Z",
"endsAt": "2026-09-04T10:30:00.000Z",
"status": "CONFIRMED",
"services": ["Haircut"],
"staffName": "Amina Khalil",
"customerDisplayName": "Sara A.",
"updatedAt": "2026-09-03T18:38:33.944Z"
}
],
"nextSince": "2026-09-03T18:38:33.944Z"
}Pass the response's nextSince back as since on your next call — it's the latest change actually returned, not the current time, so nothing gets skipped if you hit the 100-row cap.
GET /partner/v1/services returns the center's active service list (name, duration, price) if you'd like your own tool to show consistent names rather than hardcoding them.
Webhook delivery
Once enabled, youShine sends a POST to your endpoint for every booking created, cancelled, or rescheduled at the center. The payload is the exact same booking shape the pull feed returns:
{
"event": "booking.created",
"booking": {
"id": "b1a2c3d4-...",
"startsAt": "2026-09-04T10:00:00.000Z",
"endsAt": "2026-09-04T10:30:00.000Z",
"status": "CONFIRMED",
"services": ["Haircut"],
"staffName": "Amina Khalil",
"customerDisplayName": "Sara A.",
"updatedAt": "2026-09-03T18:38:33.944Z"
},
"deliveredAt": "2026-09-03T18:38:35.563Z"
}event is one of booking.created, booking.cancelled, or booking.rescheduled. Your endpoint must be HTTPS and respond with a 2xx status within 10 seconds; anything else (a non-2xx, a redirect, or a timeout) is retried once after 30 seconds before youShine gives up on that delivery. Deliveries aren't queued or replayed beyond that retry — if your endpoint is down for longer, use the pull feed to catch up.
What data is shared
Deliberately the minimum a calendar-sync tool actually needs — booking times, service names, the assigned staff member, and the customer's first name plus last initial. Full customer contact details (email, phone) are never included. Generating either credential is the center owner's own explicit choice to share this for their center; it can be revoked or rotated at any time from center-portal.
Support
Questions about integrating? Reach us via the contact form.