Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/sdurutr436/stay-sidekick/llms.txt

Use this file to discover all available pages before exploring further.

Stay Sidekick can push guest contact information from your PMS directly into Google Contacts, so your entire operations team always has current guest phone numbers available on any device — without anyone spending time on manual copy-paste between systems. The sync uses the Google People API via a standard OAuth 2.0 connection, requires no third-party credentials to be shared, and processes all guest data in memory without storing it in the Stay Sidekick database.

​
OAuth 2.0 setup

Only a company administrator can initiate the Google connection. The flow uses a standard three-step OAuth 2.0 authorization code exchange.
1

Generate the authorization URL

The admin calls the auth endpoint to receive a Google authorization URL. This URL encodes a signed state parameter to prevent CSRF attacks.
curl http://localhost/api/contactos/google/auth \
  -H "Authorization: Bearer $TOKEN"

{
  "ok": true,
  "url": "https://accounts.google.com/o/oauth2/auth?client_id=...&scope=...&state=..."
}
This endpoint requires an admin-role JWT. Non-admin users will receive 403 Forbidden.
2

User visits the URL and grants access

The admin opens the returned URL in their browser. Google displays a consent screen listing the requested scopes (Google Contacts read/write). The admin approves access.
3

Callback and token exchange

Google redirects the browser to /api/contactos/google/callback with an authorization code and the original state value. Stay Sidekick validates the state, exchanges the code for access and refresh tokens, and stores them encrypted against the company record. The browser is then redirected to the profile page in the app.If the user denies access or the state is invalid, the redirect includes a ?google_error= parameter explaining the failure (acceso_denegado, estado_invalido, codigo_invalido, or token_fallido).
Only company admins can initiate or revoke the Google connection. Regular users can see the connection status and trigger sync operations, but cannot connect or disconnect the Google account.

​
Connection status

Check whether the company’s Google account is currently connected: 
curl http://localhost/api/contactos/google/status \
  -H "Authorization: Bearer $TOKEN"

{
  "ok": true,
  "google": {
    "conectado": true,
    "email": "operaciones@miempresa.com"
  }
}
Revoke and disconnect (admin only): 
curl -X DELETE http://localhost/api/contactos/google/conexion \
  -H "Authorization: Bearer $TOKEN"
This revokes the OAuth tokens from Google’s servers and removes them from the Stay Sidekick database. To reconnect, the admin must go through the authorization flow again.

​
Sync modes

Stay Sidekick supports four workflows depending on whether your data source is a live PMS API or an XLSX file, and whether a Google account is currently connected. Choose the tab that matches your current setup.
The primary workflow. Reservations are fetched from your PMS for the specified date range, and matching contacts are created or updated in Google Contacts.
curl -X POST http://localhost/api/contactos/sincronizacion \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "desde": "2025-07-01",
    "hasta": "2025-07-31"
  }'
Response (200):
{
  "ok": true,
  "resultado": {
    "contactos_creados": 18,
    "contactos_actualizados": 4,
    "omitidos": 2
  }
}
This endpoint is rate-limited to 10 requests per hour. Both desde and hasta are optional date fields (YYYY-MM-DD).
Guest data from both the PMS API and uploaded XLSX files is processed entirely in memory and is never written to the Stay Sidekick database. The platform handles your guests’ contact information as a transient processing step, not as stored data — consistent with GDPR data minimisation principles.

​
Sync preferences

Configure how contacts are formatted and what data gets included. Preferences are stored per company and apply to all sync operations. Read current preferences: 
curl http://localhost/api/contactos/preferencias \
  -H "Authorization: Bearer $TOKEN"

{
  "ok": true,
  "preferencias": {
    "plantilla": "{NOMBRE} — {TIPOLOGIA}",
    "separador_apt": " | ",
    "formato_fecha_salida": "DD/MM/YYYY",
    "xlsx_reservas": {
      "col_checkin": 0,
      "col_nombre": 1,
      "col_tipologia": 2,
      "col_telefono": 3
    }
  }
}
Update preferences: 
curl -X PUT http://localhost/api/contactos/preferencias \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "formato_fecha_salida": "YYYYMMDD",
    "xlsx_reservas": {
      "col_checkin": 0,
      "col_nombre": 2,
      "col_tipologia": 3,
      "col_telefono": 5
    }
  }'
All preference fields are optional — send only the fields you want to change. The formato_fecha_salida field controls how dates appear in exported contacts and accepts the following values:
ValueExample
YYMMDD250715
YYYYMMDD20250715
DD/MM/YYYY15/07/2025
DD/MM/YY15/07/25
MM/DD/YYYY07/15/2025
DD-MM-YYYY15-07-2025
The xlsx_reservas object maps XLSX data columns to guest fields using zero-based column indices (col_checkin, col_nombre, col_tipologia, col_telefono).
Configure xlsx_reservas column indices once per company so that every XLSX upload is parsed consistently without needing to manually adjust the mapping each time.

Build docs developers (and LLMs) love

Get started for freeTalk to us