Skip to main content

API de Check-in

Los ejemplos muestran el header en formato de transmisión Authorization: P2S-SIGN-V1 API_KEY:TIMESTAMP:SIGNATURE. Para calcular la firma en tu código, usa el helper signedRequest en Autenticación.
La API de Check-in permite que tu backend lea el estado de presencia en el turno de tus vendedores en SalesOS — si hicieron check-in hoy, dónde, en qué turno y hasta cuándo es válido. Fue creada para componer tus propias pantallas (por ejemplo, un widget en la Home de un superapp) antes de que el usuario abra el módulo SalesOS. Es una API de solo lectura, servidor-a-servidor: consultas colaboradores por CPF o email, en lote, y SalesOS responde con el estado de hoy calculado en la zona horaria de tu empresa.

Cómo funciona

  1. Obtienes una API Key con el scope checkin:read (Admin > Integraciones > API Keys)
  2. Tu backend consulta el estado de check-in de uno o varios colaboradores (por CPF o email)
  3. SalesOS responde con el último check-in de hoy por colaborador — y, opcionalmente, conteos de engagement semana/mes
El check-in se sigue ejecutando dentro de la app SalesOS (la validación de GPS ocurre en el contexto del usuario). Esta API es para leer el estado de presencia — combínala con un deep link al módulo SalesOS en la acción “Hacer check-in”.

Autenticación

Todas las solicitudes requieren una API Key en el header Authorization:
Consulta la página de Autenticación para detalles sobre creación y gestión de API Keys.

Ambientes

Base URL: https://api.play2sell.com

Referencia del Endpoint

El endpoint acepta dos actions mediante el campo action: checkin_status y checkin_engagement. Cada colaborador se identifica por CPF (cualquier formato — los dígitos se normalizan) o email. Cuando se envían ambos, el CPF prevalece.

Action: checkin_status

Último check-in de hoy por colaborador. “Hoy” se calcula en la zona horaria de tu empresa (devuelta como timezone / reference_date en la respuesta) — nunca en UTC.

Schema de la solicitud

string
requerido
Debe ser "checkin_status"
array
requerido
Array de referencias de colaborador (máx. 500)
string
CPF, cualquier formato (52998224725 o 529.982.247-25). Debe contener exactamente 11 dígitos.
string
Email — usado solo cuando cpf no se envía

Ejemplo

Respuesta (200):

Campos de la respuesta

boolean
Si el CPF/email correspondió a un colaborador de tu empresa. Un colaborador desconocido viene como found: false — no es un error, y el array mantiene el mismo orden de la solicitud.
boolean
Si el colaborador tiene al menos un check-in no rechazado hoy (zona horaria de la empresa).
boolean
true cuando el último check-in está activo/aprobado y el turno aún no expiró — es decir, el colaborador está de turno ahora.
object
Check-in más reciente de hoy. Omitido cuando no hay ninguno. mode es geo (presencial con GPS), home (home office) u offline. status puede ser active, approved, pending (esperando aprobación del líder), expired (turno finalizado normalmente) o checkout.
string
Vínculo del colaborador con tu empresa (active, inactive, …). Un colaborador puede ser encontrado y estar inactivo.

Action: checkin_engagement

Todo lo que devuelve checkin_status, más conteos de engagement semana/mes por colaborador. Lotes limitados a 100.
string
requerido
Debe ser "checkin_engagement"
array
requerido
Array de referencias de colaborador (máx. 100)

Ejemplo

Cada colaborador encontrado gana un objeto engagement:
  • checkins — check-ins en la semana/mes corriente (zona horaria de la empresa; expired cuenta — es el fin normal de un turno)
  • presence_days — días distintos con al menos un check-in

Modo self (sesión federada)

Si tu app ya posee una sesión federada de SalesOS — el JWT devuelto por un login personalizado, como la federación del Superapp — el mismo endpoint responde por el propio usuario del token, sin API key:
  • La identidad viene exclusivamente del token verificado — no envíes collaborators. Una solicitud con ese campo se rechaza con SELF_MODE_NO_COLLABORATORS: un token de usuario nunca consulta a otras personas.
  • El alcance de empresa viene de la sesión; la respuesta tiene exactamente el mismo formato, con un único ítem en collaborators.
  • checkin_engagement funciona de la misma manera ({ "action": "checkin_engagement" }).
Usa el modo self en pantallas renderizadas dentro de la app autenticada; usa la API key (S2S) cuando tu backend compone pantallas antes de que el usuario tenga sesión en SalesOS — como un widget en la Home de un superapp.

Manejo de Errores

Todos los errores siguen la estructura compartida:
Body inválido, lote sobre el límite, CPF sin 11 dígitos, o ítem sin cpf ni email. El array details indica el index del ítem.
API key ausente, inválida o expirada, o la firma no coincide.
API key válida, pero sin el scope checkin:read.
Solo se acepta POST.
Demasiadas solicitudes en esta hora. Espera retry_after segundos y reintenta.
Error interno. Reintenta con backoff exponencial (2s, 4s, 8s).
Un colaborador desconocido no es un error. La solicitud responde 200 con found: false en ese ítem — un CPF equivocado nunca rompe la renderización de la Home entera.

Rate Limits


Seguridad

  • Solo lectura: esta API nunca crea ni modifica check-ins
  • Cada key está limitada a una única empresa — un CPF de otra empresa responde found: false
  • Solicitudes firmadas con HMAC (P2S-SIGN-V1) y registradas para auditoría; los documentos nunca se escriben en logs
Nunca expongas tu API key en código client-side. Esta API debe llamarse solo desde tu backend.

Próximos pasos

Autenticación

Aprende a crear y gestionar API Keys

Soporte

¿Necesitas ayuda? Habla con nuestro equipo