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 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. Con el scope checkin:write, también hace el check-in y el check-out de un colaborador.

Cómo funciona

Obtienes una API Key con el scope checkin:read (Admin > Integraciones > API Keys)
Tu backend consulta el estado de check-in de uno o varios colaboradores (por CPF o email)
SalesOS responde con el último check-in de hoy por colaborador — y, opcionalmente, conteos de engagement semana/mes
Opcionalmente, tu backend hace check-in y check-out con una key que también tenga checkin:write, reenviando la lectura de GPS del celular del colaborador

Autenticación

Todas las solicitudes requieren una API Key en el header Authorization:

Authorization: P2S-SIGN-V1 API_KEY:TIMESTAMP:SIGNATURE

Consulta la página de Autenticación para detalles sobre creación y gestión de API Keys.

Propiedad	Detalles
Header	`Authorization: P2S-SIGN-V1 API_KEY:TIMESTAMP:SIGNATURE`
Scope requerido	`checkin:read` para lectura y `checkin_options`; `checkin:write` para `checkin_create` y `checkin_checkout`
Rate limit	Configurable por key (por defecto: 1000 solicitudes/hora)
Formato de la key	`sk_live_` (producción) o `sk_test_` (pruebas)

Ambientes

Producción
Staging

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

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

Referencia del Endpoint

POST https://api.play2sell.com/functions/v1/checkin-partner-api

El endpoint acepta estas actions mediante el campo action:

Action	Scope	Qué hace
`checkin_status`	`checkin:read`	Estado de hoy, en lote
`checkin_engagement`	`checkin:read`	Estado más conteos semana/mes, en lote
`checkin_options`	`checkin:read`	Qué puede hacer un colaborador ahora
`checkin_create`	`checkin:write`	Check-in de un colaborador
`checkin_checkout`	`checkin:write`	Check-out de un colaborador

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

curl -X POST https://api.play2sell.com/functions/v1/checkin-partner-api \
  -H "Authorization: P2S-SIGN-V1 API_KEY:TIMESTAMP:SIGNATURE" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "checkin_status",
    "collaborators": [
      { "cpf": "529.982.247-25" },
      { "email": "joao@tuempresa.com" }
    ]
  }'

Respuesta (200):

{
  "data": {
    "timezone": "America/Sao_Paulo",
    "reference_date": "2026-07-19",
    "collaborators": [
      {
        "cpf": "52998224725",
        "found": true,
        "user_id": "8f14e45f-...",
        "name": "Maria Santos",
        "membership_status": "active",
        "checked_in_today": true,
        "on_duty_now": true,
        "latest_checkin": {
          "status": "active",
          "mode": "geo",
          "shift": "afternoon",
          "checked_in_at": "2026-07-19T16:03:21+00:00",
          "shift_expires_at": "2026-07-19T21:00:00+00:00",
          "location_id": "c81e728d-...",
          "location_name": "Plantão Morumbi",
          "location": { "lat": -23.6012, "lng": -46.7003, "accuracy": 14 }
        },
        "org_unit_id": "a87ff679-..."
      },
      {
        "email": "joao@tuempresa.com",
        "found": true,
        "user_id": "45c48cce-...",
        "name": "Joao Silva",
        "membership_status": "active",
        "checked_in_today": false,
        "on_duty_now": false
      }
    ],
    "total": 2,
    "found": 2
  },
  "meta": { "request_id": "a1b2c3d4-...", "timestamp": "2026-07-19T18:00:00.000Z" }
}

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. location trae la lectura de GPS grabada en el check-in: lat, lng, accuracy (metros) y, para check-ins hechos por esta API, captured_at (cuándo el celular leyó el GPS). Ausente cuando el check-in no tuvo GPS (home office, checkout).

string

Vínculo del colaborador con tu empresa (active, inactive, …). Un colaborador puede ser encontrado y estar inactivo.

Recorrido del dia (`include_day`)

Envie "include_day": true en checkin_status para recibir, ademas del estado actual, como va el dia turno por turno y cuando se habilita el boton de nuevo. Es lo que una pantalla de inicio necesita para componer el bloque de check-in sin abrir el modulo de SalesOS.

curl -X POST https://api.play2sell.com/functions/v1/checkin-partner-api \
  -H "Authorization: P2S-SIGN-V1 API_KEY:TIMESTAMP:SIGNATURE" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "checkin_status",
    "collaborators": [{ "cpf": "52998224725" }],
    "include_day": true
  }'

Respuesta (200):

{
  "data": {
    "timezone": "America/Sao_Paulo",
    "reference_date": "2026-08-13",
    "shifts": [
      { "key": "morning",   "label": "Manha", "start": "09:00", "end": "13:59" },
      { "key": "afternoon", "label": "Tarde", "start": "14:00", "end": "18:59" }
    ],
    "collaborators": [
      {
        "cpf": "52998224725",
        "found": true,
        "day": {
          "shifts": [
            { "key": "morning",   "label": "Manha", "start": "09:00", "end": "13:59",
              "state": "completed", "checked_in_at": "2026-08-13T12:04:00.000Z" },
            { "key": "afternoon", "label": "Tarde", "start": "14:00", "end": "18:59",
              "state": "upcoming" }
          ],
          "shifts_source": "tenant_default",
          "action": { "state": "waiting", "opens_at": "2026-08-13T17:00:00.000Z" }
        }
      }
    ]
  }
}

Los turnos salen una sola vez arriba, no repetidos por persona. En un lote de 500 colaboradores esa es la diferencia entre una respuesta liviana y una de megabytes.

Campos

Campo	Significado
`shifts[]` (nivel superior)	Los turnos habilitados de su empresa, ordenados por hora de inicio
`shifts[].label`	El nombre del turno tal como su empresa lo configuro — renderice este valor
`day.shifts[].state`	`completed` · `open` · `upcoming` · `missed`
`day.shifts[].checked_in_at`	Cuando ocurrio el check-in de ese turno. Ausente cuando no hubo — verifica la presencia del campo, no `null`
`day.action.state`	`available` cuando hay un turno abierto sin check-in; si no, `waiting`
`day.action.opens_at`	Cuando abre el proximo turno. Ausente mientras `state` es `available` (hay un turno abierto ahora) y cuando el dia termino
`day.shifts_source`	Qué horario se usó: `location` o `tenant_default`
`day.location_id`	La unidad cuyo horario se usó, cuando `shifts_source` es `location`

Una unidad puede tener horarios propios, y esos ganan. El arreglo shifts de arriba es el predeterminado de su empresa. Cuando la persona hace check-in en una unidad con horario propio, day.shifts sigue a esa unidad y day.shifts_source lo declara. Al dibujar la pantalla de alguien, lea el recorrido de la persona, no el arreglo de arriba.Antes del primer check-in del día no hay unidad que resolver, así que se usa el predeterminado de la empresa.

La cantidad de turnos es de su empresa, no es fija. Puede tener dos, tres o ninguno, con sus propias etiquetas y horarios. Construya la pantalla a partir del arreglo; nunca asuma tres posiciones ni horarios especificos.

Lee opens_at junto con state. Con state: "available" viene ausente porque hay un turno abierto ahora. Con state: "waiting" y sin opens_at, el dia termino y no hay proxima apertura hoy — la pantalla no debe mostrar una cuenta regresiva que cruce la medianoche.

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

curl -X POST https://api.play2sell.com/functions/v1/checkin-partner-api \
  -H "Authorization: P2S-SIGN-V1 API_KEY:TIMESTAMP:SIGNATURE" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "checkin_engagement",
    "collaborators": [{ "cpf": "52998224725" }]
  }'

Cada colaborador encontrado gana un objeto engagement:

{
  "engagement": {
    "week":  { "checkins": 9,  "presence_days": 5 },
    "month": { "checkins": 34, "presence_days": 17 }
  }
}

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

Registrar check-ins

Con el scope checkin:write, tu backend puede hacer el check-in y el check-out de un colaborador — por ejemplo, desde un botón “Hacer check-in” en tu propia Home. El efecto es el mismo que un check-in hecho en la app SalesOS: el colaborador entra en la fila de leads, recibe el turno y la hora en que termina, gana puntos, y se disparan los webhooks checkin.confirmed / checkin.checked_out.

Esta API escribe. A diferencia de las actions de lectura de arriba, checkin_create y checkin_checkout cambian quién recibe leads. Requieren una key con checkin:write; una key solo con checkin:read responde 403 con code: "scope_insufficient".

Las actions de escritura manejan un colaborador por solicitud, enviado en collaborator (un objeto, no una lista). En la escritura, “no encontrado” es un error — no existe escritura parcial:

Situación	HTTP	`code`
El CPF/email no pertenece a tu empresa	404	`COLLABORATOR_NOT_FOUND`
Colaborador encontrado, pero inactivo	409	`COLLABORATOR_INACTIVE`
Más de una persona coincide	409	`COLLABORATOR_AMBIGUOUS`

Action: checkin_options

Lo que tu pantalla puede ofrecer ahora, para mostrar solo el botón que va a funcionar. Solo lectura — requiere checkin:read.

curl -X POST https://api.play2sell.com/functions/v1/checkin-partner-api \
  -H "Authorization: P2S-SIGN-V1 API_KEY:TIMESTAMP:SIGNATURE" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "checkin_options",
    "collaborator": { "cpf": "52998224725" },
    "location": { "lat": -23.6, "lng": -46.7, "accuracy": 15, "captured_at": "2026-09-21T14:03:00Z" }
  }'

location es opcional. Cuando se envía, locations vuelve ordenado por distancia y duty indica si algún local está al alcance.

{
  "data": {
    "timezone": "America/Sao_Paulo",
    "current_shift": { "key": "afternoon", "label": "Tarde", "ends_at": "2026-09-21T20:59:00.000Z" },
    "on_duty_now": false,
    "modes": [
      { "key": "duty", "label": "Com Geolocalização", "requires_geo": true, "available": true },
      { "key": "home", "label": "Sem Geolocalização", "requires_geo": false, "available": false,
        "unavailable_reason": "HOME_SHIFT_NOT_ALLOWED" }
    ],
    "locations": [
      { "id": "c81e728d-...", "name": "Plantão Morumbi", "distance_meters": 42, "radius_meters": 100, "within_radius": true }
    ]
  }
}

unavailable_reason usa los mismos códigos que devolvería un checkin_create (MODE_DISABLED, TOO_FAR, HOME_OUTSIDE_SHIFT, HOME_SHIFT_NOT_ALLOWED, PRIOR_GEO_REQUIRED, LOCATION_NOT_FOUND). Las etiquetas de modos y turnos son configuración de tu empresa — muéstralas tal como llegan.

Action: checkin_create

curl -X POST https://api.play2sell.com/functions/v1/checkin-partner-api \
  -H "Authorization: P2S-SIGN-V1 API_KEY:TIMESTAMP:SIGNATURE" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 3f2b8c1e-5d4a-4b7e-9f10-2a6c8d9e0f11" \
  -d '{
    "action": "checkin_create",
    "collaborator": { "cpf": "52998224725" },
    "mode": "duty",
    "location": { "lat": -23.6, "lng": -46.7, "accuracy": 15, "captured_at": "2026-09-21T14:03:00Z" },
    "location_id": "c81e728d-...",
    "client": { "app": "tu-home", "version": "1.0.0" }
  }'

string

requerido

duty (turno presencial, requiere location) o home (home office).

object

La lectura de GPS del dispositivo, capturada en el celular del colaborador y reenviada por tu backend. Obligatoria para duty: lat, lng, accuracy (metros) y captured_at (ISO 8601 — cuándo el celular leyó el GPS).

string

El local de turno que eligió el colaborador. Opcional — sin él, SalesOS elige el local más cercano dentro de su radio.

object

Tu app y versión (app, version). Se guarda junto con el check-in para auditoría.

Respuesta (201):

{
  "data": {
    "checkin_id": "5f0c...",
    "status": "active",
    "mode": "duty",
    "on_duty_now": true,
    "queue_eligible": true,
    "shift": "afternoon",
    "shift_label": "Tarde",
    "shift_expires_at": "2026-09-21T20:59:00.000Z",
    "checked_in_at": "2026-09-21T14:03:05.000Z",
    "location_id": "c81e728d-...",
    "location_name": "Plantão Morumbi",
    "distance_meters": 42,
    "location": { "lat": -23.6, "lng": -46.7, "accuracy": 15, "captured_at": "2026-09-21T14:03:00Z" }
  },
  "meta": { "request_id": "a1b2c3d4-...", "timestamp": "2026-09-21T14:03:05.120Z" }
}

location devuelve la lectura de GPS que quedó grabada — misma forma que latest_checkin.location de checkin_status. Ausente cuando no se envió GPS. Un check-in nuevo cierra el check-in activo anterior del colaborador, igual que en la app. Es válido hasta shift_expires_at — tu app no necesita seguir enviando señales de vida.

Requisitos de la ubicación

La lectura de GPS llega por tu backend, así que SalesOS verifica que sea reciente y precisa antes de confiar en ella:

Regla	Límite	Rechazo
Frescura	`captured_at` con como máximo 60 s (y como máximo 10 s en el futuro, por la diferencia de reloj del celular)	`400 STALE_LOCATION`
Precisión	`accuracy` no mayor que el radio del local elegido (tu empresa puede definir su propio límite)	`422 LOW_ACCURACY`
Distancia	Dentro del radio del local elegido — o de algún local, cuando no se envía `location_id`	`422 TOO_FAR`

Lee el GPS cuando el usuario toca el botón, no cuando se abre la pantalla. Una lectura hecha al abrir la pantalla suele llegar vencida, y una lectura en interiores suele ser imprecisa — ambas se rechazan, y pedirle al usuario que salga a un lugar abierto y vuelva a intentarlo lo resuelve.

Un check-in rechazado no graba nada: el colaborador queda exactamente como estaba.

Action: checkin_checkout

Cierra el check-in activo antes del fin del turno. El colaborador sale de la fila de leads en el acto y se dispara checkin.checked_out.

curl -X POST https://api.play2sell.com/functions/v1/checkin-partner-api \
  -H "Authorization: P2S-SIGN-V1 API_KEY:TIMESTAMP:SIGNATURE" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 7a1c2e3f-0b4d-4e5f-8a6b-9c0d1e2f3a4b" \
  -d '{
    "action": "checkin_checkout",
    "collaborator": { "cpf": "52998224725" },
    "reason": "user_requested",
    "client": { "app": "tu-home", "version": "1.0.0" }
  }'

Respuesta (200):

{
  "data": {
    "status": "checkout",
    "on_duty_now": false,
    "already_checked_out": false,
    "checked_out_at": "2026-09-21T17:10:00.000Z",
    "previous_checkin_id": "5f0c..."
  }
}

Sin check-in activo, la respuesta sigue siendo 200, con "already_checked_out": true, y no se graba nada — un doble toque nunca rompe tu pantalla.

Reintentos e `Idempotency-Key`

Envía el header Idempotency-Key (8 a 128 caracteres; un UUID sirve) en checkin_create y checkin_checkout. Repetir la solicitud con la misma clave dentro de 24 horas:

devuelve la misma respuesta, con el header Idempotency-Replayed: true, sin crear nada nuevo;
con un cuerpo distinto, responde 409 IDEMPOTENCY_KEY_REUSED;
mientras la primera solicitud sigue en curso, responde 409 IDEMPOTENCY_IN_PROGRESS — reintenta en unos segundos.

Una solicitud rechazada (4xx) no consume la clave: después de corregir la causa (una lectura de GPS nueva, por ejemplo), puedes reintentar con la misma clave.

El timestamp de la firma vale 30 segundos, así que cada reintento debe firmarse de nuevo — la Idempotency-Key es lo que une los intentos.

Mensajes para el colaborador

Los errores de escritura traen un message en portugués de Brasil, escrito para mostrarse directamente al colaborador (por ejemplo: “Você está a 180 m de Plantão Morumbi. Chegue a até 100 m para fazer o check-in.”). Decide la lógica por el code, nunca por el texto.

HTTP	`code`	Cuándo
400	`VALIDATION_ERROR`	Cuerpo inválido; `details` indica el campo
400	`GEO_REQUIRED`	`duty` sin `location`
400	`STALE_LOCATION`	Lectura de GPS con más de 60 s
404	`COLLABORATOR_NOT_FOUND`	El CPF/email no pertenece a tu empresa
404	`LOCATION_NOT_FOUND`	`location_id` inexistente o inactivo, o ningún local activo
409	`COLLABORATOR_INACTIVE` / `COLLABORATOR_AMBIGUOUS`	Ver arriba
409	`IDEMPOTENCY_KEY_REUSED` / `IDEMPOTENCY_IN_PROGRESS`	Ver reintentos
422	`TOO_FAR`	Fuera del radio; `details` trae distancia, radio y local
422	`LOW_ACCURACY`	GPS demasiado impreciso; `details` trae ambos valores
422	`MODE_DISABLED`	El modo está desactivado en tu empresa
422	`HOME_OUTSIDE_SHIFT` / `HOME_SHIFT_NOT_ALLOWED`	Home office fuera de los turnos que tu empresa permite
422	`PRIOR_GEO_REQUIRED`	Tu empresa exige un check-in presencial más temprano el mismo día antes del home office
429	`RATE_LIMITED`	Más de 10 escrituras para el mismo colaborador en 10 minutos; ver `Retry-After`
503	`PRIOR_GEO_CHECK_UNAVAILABLE`	Falla temporal al verificar la regla anterior — reintenta

Modo self (token del usuario del SSO)

Si tu app ya posee el token de un usuario que entró por SSO, el mismo endpoint responde por el propio usuario del token, sin API key:

curl -X POST https://api.play2sell.com/functions/v1/checkin-partner-api \
  -H "Authorization: Bearer SESSION_JWT" \
  -H "Content-Type: application/json" \
  -d '{ "action": "checkin_status" }'

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" }).
Las actions de escritura y checkin_options son solo para socios: con token de usuario responden 400 SELF_MODE_NOT_SUPPORTED. Dentro de la app SalesOS, el check-in lo hace la propia app.

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:

{
  "error": {
    "code": "ERROR_CODE",
    "message": "Descripción legible",
    "details": []
  }
}

Son dos formatos, no uno. El bloque anterior es el error del endpoint. Las fallas en la capa de autenticación responden antes de que el endpoint corra, con error como cadena:

{ "error": "Missing Authorization header", "code": "header_missing" }

El código que asume error.code lee undefined en toda falla de autenticación. Ramifique por el tipo — vea Convenciones de la API.

400 — VALIDATION_ERROR

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.

401 — capa de autenticación

API key ausente, desconocida o expirada, o la firma no coincide. La respuesta trae error como cadena y códigos como header_missing, api_key_not_found, signature_invalid, timestamp_too_old.

403 — scope_insufficient

API key válida, pero sin el scope que requiere la action (checkin:read, o checkin:write para escritura). Responde la capa de autenticación: { "error": "...", "code": "scope_insufficient", "missing_scopes": ["checkin:write"] }.

405 — METHOD_NOT_ALLOWED

Solo se acepta POST.

429 — RATE_LIMITED

Demasiadas escrituras para el mismo colaborador (10 en 10 minutos). Espera los segundos de Retry-After y reintenta. Las actions de escritura tienen su propia tabla de errores en Registrar check-ins.

500 — SERVER_ERROR

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

Límite	Valor
Solicitudes por hora (por defecto)	1000
Máx. colaboradores por `checkin_status`	500
Máx. colaboradores por `checkin_engagement`	100
Escrituras por colaborador (`checkin_create` + `checkin_checkout`)	10 cada 10 minutos

Seguridad

La lectura requiere checkin:read; crear o cerrar check-ins requiere checkin:write — emite keys de escritura solo para el backend dueño del botón
Todo check-in creado por la API se guarda con su origen, la key que lo creó, tu client y la lectura de GPS original, para auditoría
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.

Descripción General

Integraciones

API de Check-in

API de Check-in

Cómo funciona

Autenticación

Ambientes

Referencia del Endpoint

Action: checkin_status

Schema de la solicitud

Ejemplo

Campos de la respuesta

Recorrido del dia (`include_day`)

Campos

Action: checkin_engagement

Ejemplo

Registrar check-ins

Action: checkin_options

Action: checkin_create

Requisitos de la ubicación

Action: checkin_checkout

Reintentos e `Idempotency-Key`

Mensajes para el colaborador

Modo self (token del usuario del SSO)

Manejo de Errores

Rate Limits

Seguridad

Próximos pasos

Autenticación

Soporte

​API de Check-in

​Cómo funciona

​Autenticación

​Ambientes

​Referencia del Endpoint

​Action: checkin_status

​Schema de la solicitud

​Ejemplo

​Campos de la respuesta

​Recorrido del dia (include_day)

​Campos

​Action: checkin_engagement

​Ejemplo

​Registrar check-ins

​Action: checkin_options

​Action: checkin_create

​Requisitos de la ubicación

​Action: checkin_checkout

​Reintentos e Idempotency-Key

​Mensajes para el colaborador

​Modo self (token del usuario del SSO)

​Manejo de Errores

​Rate Limits

​Seguridad

​Próximos pasos

Autenticación

Soporte

API de Check-in

Cómo funciona

Autenticación

Ambientes

Referencia del Endpoint

Action: checkin_status

Schema de la solicitud

Ejemplo

Campos de la respuesta

Recorrido del dia (`include_day`)

Campos

Action: checkin_engagement

Ejemplo

Registrar check-ins

Action: checkin_options

Action: checkin_create

Requisitos de la ubicación

Action: checkin_checkout

Reintentos e `Idempotency-Key`

Mensajes para el colaborador

Modo self (token del usuario del SSO)

Manejo de Errores

Rate Limits

Seguridad

Próximos pasos