API de Check-in

Os exemplos abaixo mostram o header no formato de transmissão Authorization: P2S-SIGN-V1 API_KEY:TIMESTAMP:SIGNATURE. Para calcular a assinatura no seu código, use o helper signedRequest em Autenticação.

A API de Check-in permite que o seu backend leia o estado de presença no plantão dos seus vendedores no SalesOS — fizeram check-in hoje, onde, em qual turno e até quando ele vale. Ela foi criada para compor as suas próprias telas (por exemplo, um widget na Home de um superapp) antes mesmo de o usuário abrir o módulo SalesOS. É uma API servidor-a-servidor: você consulta colaboradores por CPF ou email, em lote, e o SalesOS responde com o estado de hoje calculado no fuso horário da sua empresa. Com o scope checkin:write, ela também faz o check-in e o check-out de um colaborador.

Como funciona

Você obtém uma API Key com o scope checkin:read (Admin > Integrações > API Keys)
Seu backend consulta o estado de check-in de um ou vários colaboradores (por CPF ou email)
O SalesOS responde com o último check-in de hoje por colaborador — e, opcionalmente, contagens de engajamento semana/mês
Opcionalmente, seu backend faz check-in e check-out com uma key que também tenha checkin:write, repassando a leitura de GPS do celular do colaborador

Autenticação

Todas as requisições exigem uma API Key no header Authorization:

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

Veja a página de Autenticação para detalhes sobre criação e gestão de API Keys.

Propriedade	Detalhes
Header	`Authorization: P2S-SIGN-V1 API_KEY:TIMESTAMP:SIGNATURE`
Scope exigido	`checkin:read` para leitura e `checkin_options`; `checkin:write` para `checkin_create` e `checkin_checkout`
Rate limit	Configurável por key (padrão: 1000 requisições/hora)
Formato da key	`sk_live_` (produção) ou `sk_test_` (teste)

Ambientes

Produção
Staging

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

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

Referência do Endpoint

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

O endpoint aceita estas actions pelo campo action:

Action	Scope	O que faz
`checkin_status`	`checkin:read`	Estado de hoje, em lote
`checkin_engagement`	`checkin:read`	Estado mais contagens semana/mês, em lote
`checkin_options`	`checkin:read`	O que um colaborador pode fazer agora
`checkin_create`	`checkin:write`	Check-in de um colaborador
`checkin_checkout`	`checkin:write`	Check-out de um colaborador

Cada colaborador é identificado por CPF (qualquer formato — os dígitos são normalizados) ou email. Quando os dois são enviados, o CPF prevalece.

Action: checkin_status

Último check-in de hoje por colaborador. “Hoje” é calculado no fuso horário da sua empresa (retornado como timezone / reference_date na resposta) — nunca em UTC.

Schema da requisição

string

obrigatório

Deve ser "checkin_status"

array

obrigatório

Array de referências de colaborador (máx. 500)

string

CPF, qualquer formato (52998224725 ou 529.982.247-25). Deve conter exatamente 11 dígitos.

string

Email — usado apenas quando cpf não é enviado

Exemplo

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@suaempresa.com" }
    ]
  }'

Resposta (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@suaempresa.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 da resposta

boolean

Se o CPF/email correspondeu a um colaborador da sua empresa. Colaborador desconhecido vem como found: false — não é erro, e o array mantém a mesma ordem da requisição.

boolean

Se o colaborador tem ao menos um check-in não-rejeitado hoje (fuso da empresa).

boolean

true quando o último check-in está ativo/aprovado e o turno ainda não expirou — ou seja, o colaborador está em plantão agora.

object

Check-in mais recente de hoje. Omitido quando não há nenhum. mode é geo (presencial com GPS), home (home office) ou offline. status pode ser active, approved, pending (aguardando aprovação do líder), expired (turno encerrado normalmente) ou checkout. location traz a leitura de GPS gravada no check-in: lat, lng, accuracy (metros) e, para check-ins feitos por esta API, captured_at (quando o celular leu o GPS). Ausente quando o check-in não teve GPS (home office, checkout).

string

Vínculo do colaborador com a sua empresa (active, inactive, …). Um colaborador pode ser encontrado e estar inativo.

Trilha do dia (`include_day`)

Envie "include_day": true em checkin_status para receber, além do estado atual, como está o dia turno a turno e quando o botão libera de novo. É o que uma tela inicial precisa para desenhar o bloco de check-in sem abrir o módulo do 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
  }'

Resposta (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" }
        }
      }
    ]
  }
}

Os turnos saem uma vez no topo, não repetidos por pessoa. Num lote de 500 colaboradores isso é a diferença entre uma resposta enxuta e uma de megabytes.

Campos

Campo	Significado
`shifts[]` (topo)	Os turnos habilitados da sua empresa, ordenados pelo horário de início
`shifts[].label`	O nome do turno como a sua empresa o configurou — renderize este valor
`day.shifts[].state`	`completed` · `open` · `upcoming` · `missed`
`day.shifts[].checked_in_at`	Quando o check-in daquele turno aconteceu. Ausente quando não houve — teste a presença do campo, não `null`
`day.action.state`	`available` quando há turno aberto ainda sem check-in; senão `waiting`
`day.action.opens_at`	Quando o próximo turno abre. Ausente enquanto `state` é `available` (há turno aberto agora) e quando o dia acabou
`day.shifts_source`	Qual grade foi usada: `location` ou `tenant_default`
`day.location_id`	A unidade cuja grade foi usada, quando `shifts_source` é `location`

Uma unidade pode ter horários próprios, e eles vencem. O array shifts do topo é o padrão da sua empresa. Quando a pessoa faz check-in numa unidade com grade própria, day.shifts segue aquela unidade e day.shifts_source diz isso. Ao desenhar a tela de alguém, leia a trilha da pessoa, não o array do topo.Antes do primeiro check-in do dia não há unidade a resolver, então vale o padrão da empresa.

A quantidade de turnos é da sua empresa, não fixa. Ela pode ter dois, três ou nenhum, com rótulos e horários próprios. Monte a tela a partir do array — nunca assuma três posições nem horários específicos.

Leia opens_at junto com state. Com state: "available" ele vem ausente porque há um turno aberto agora. Com state: "waiting" e sem opens_at, o dia acabou e não há próxima abertura hoje — a tela não deve exibir uma contagem atravessando a virada do dia.

Action: checkin_engagement

Tudo que checkin_status retorna, mais contagens de engajamento semana/mês por colaborador. Lotes limitados a 100.

string

obrigatório

Deve ser "checkin_engagement"

array

obrigatório

Array de referências de colaborador (máx. 100)

Exemplo

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 ganha um objeto engagement:

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

checkins — check-ins na semana/mês corrente (fuso da empresa; expired conta — é o fim normal de um turno)
presence_days — dias distintos com ao menos um check-in

Registrando check-ins

Com o scope checkin:write, seu backend pode fazer o check-in e o check-out de um colaborador — por exemplo, a partir de um botão “Fazer check-in” na sua própria Home. O efeito é o mesmo de um check-in feito no app SalesOS: o colaborador entra na fila de leads, recebe o turno e o horário em que ele termina, ganha pontos, e os webhooks checkin.confirmed / checkin.checked_out disparam.

Esta API grava. Diferente das actions de leitura acima, checkin_create e checkin_checkout mudam quem recebe lead. Elas exigem uma key com checkin:write; uma key só com checkin:read responde 403 com code: "scope_insufficient".

As actions de escrita tratam um colaborador por requisição, enviado em collaborator (um objeto, não uma lista). Na escrita, “não encontrado” é erro — não existe escrita parcial:

Situação	HTTP	`code`
CPF/email não pertence à sua empresa	404	`COLLABORATOR_NOT_FOUND`
Colaborador encontrado, mas inativo	409	`COLLABORATOR_INACTIVE`
Mais de uma pessoa corresponde	409	`COLLABORATOR_AMBIGUOUS`

Action: checkin_options

O que a sua tela pode oferecer agora, para mostrar só o botão que vai funcionar. Somente leitura — exige 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 é opcional. Quando enviado, locations volta ordenado pela distância e duty diz se algum local está ao 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 os mesmos códigos que um checkin_create devolveria (MODE_DISABLED, TOO_FAR, HOME_OUTSIDE_SHIFT, HOME_SHIFT_NOT_ALLOWED, PRIOR_GEO_REQUIRED, LOCATION_NOT_FOUND). Os rótulos de modos e turnos são configuração da sua empresa — exiba como vierem.

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": "sua-home", "version": "1.0.0" }
  }'

string

obrigatório

duty (plantão presencial, exige location) ou home (home office).

object

A leitura de GPS do aparelho, capturada no celular do colaborador e repassada pelo seu backend. Obrigatória para duty: lat, lng, accuracy (metros) e captured_at (ISO 8601 — quando o celular leu o GPS).

string

O local de plantão escolhido pelo colaborador. Opcional — sem ele, o SalesOS escolhe o local mais próximo dentro do raio.

object

Seu app e versão (app, version). Guardado junto com o check-in para auditoria.

Resposta (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 devolve a leitura de GPS que ficou gravada — mesma forma do latest_checkin.location do checkin_status. Ausente quando não foi enviado GPS. Um check-in novo encerra o check-in ativo anterior do colaborador, exatamente como no app. Ele vale até shift_expires_at — seu app não precisa ficar enviando sinal de vida.

Requisitos da localização

A leitura de GPS chega pelo seu backend, então o SalesOS confere se ela é recente e precisa antes de confiar nela:

Regra	Limite	Recusa
Frescor	`captured_at` com no máximo 60 s (e no máximo 10 s no futuro, pela diferença de relógio do celular)	`400 STALE_LOCATION`
Precisão	`accuracy` não maior que o raio do local escolhido (sua empresa pode definir um limite próprio)	`422 LOW_ACCURACY`
Distância	Dentro do raio do local escolhido — ou de algum local, quando `location_id` não é enviado	`422 TOO_FAR`

Leia o GPS quando o usuário tocar no botão, não quando a tela abrir. Uma leitura feita ao abrir a tela costuma chegar vencida, e uma leitura em ambiente fechado costuma ser imprecisa — as duas são recusadas, e pedir para o usuário ir a um lugar aberto e tentar de novo resolve.

Um check-in recusado não grava nada: o colaborador continua exatamente como estava.

Action: checkin_checkout

Encerra o check-in ativo antes do fim do turno. O colaborador sai da fila de leads na hora e checkin.checked_out dispara.

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": "sua-home", "version": "1.0.0" }
  }'

Resposta (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..."
  }
}

Sem check-in ativo, a resposta continua 200, com "already_checked_out": true, e nada é gravado — um clique duplo nunca quebra a sua tela.

Novas tentativas e `Idempotency-Key`

Envie o header Idempotency-Key (8 a 128 caracteres; um UUID serve) em checkin_create e checkin_checkout. Repetir a requisição com a mesma chave em até 24 horas:

devolve a mesma resposta, com o header Idempotency-Replayed: true, sem criar nada novo;
com um corpo diferente, responde 409 IDEMPOTENCY_KEY_REUSED;
enquanto a primeira requisição ainda está rodando, responde 409 IDEMPOTENCY_IN_PROGRESS — tente de novo em alguns segundos.

Uma requisição recusada (4xx) não consome a chave: depois de corrigir a causa (uma leitura de GPS nova, por exemplo), você pode tentar de novo com a mesma chave.

O timestamp da assinatura vale por 30 segundos, então cada nova tentativa precisa ser assinada de novo — é a Idempotency-Key que liga as tentativas.

Mensagens para o corretor

Os erros de escrita trazem uma message em português, escrita para ser exibida direto ao corretor (por exemplo: “Você está a 180 m de Plantão Morumbi. Chegue a até 100 m para fazer o check-in.”). Decida a lógica pelo code, nunca pelo texto.

HTTP	`code`	Quando
400	`VALIDATION_ERROR`	Corpo inválido; `details` aponta o campo
400	`GEO_REQUIRED`	`duty` sem `location`
400	`STALE_LOCATION`	Leitura de GPS com mais de 60 s
404	`COLLABORATOR_NOT_FOUND`	CPF/email não pertence à sua empresa
404	`LOCATION_NOT_FOUND`	`location_id` inexistente ou inativo, ou nenhum local ativo
409	`COLLABORATOR_INACTIVE` / `COLLABORATOR_AMBIGUOUS`	Veja acima
409	`IDEMPOTENCY_KEY_REUSED` / `IDEMPOTENCY_IN_PROGRESS`	Veja novas tentativas
422	`TOO_FAR`	Fora do raio; `details` traz distância, raio e local
422	`LOW_ACCURACY`	GPS impreciso demais; `details` traz os dois valores
422	`MODE_DISABLED`	O modo está desligado na sua empresa
422	`HOME_OUTSIDE_SHIFT` / `HOME_SHIFT_NOT_ALLOWED`	Home office fora dos turnos que a sua empresa permite
422	`PRIOR_GEO_REQUIRED`	Sua empresa exige um check-in presencial mais cedo no mesmo dia antes do home office
429	`RATE_LIMITED`	Mais de 10 escritas para o mesmo colaborador em 10 minutos; veja `Retry-After`
503	`PRIOR_GEO_CHECK_UNAVAILABLE`	Falha temporária ao conferir a regra acima — tente de novo

Modo self (token do usuário do SSO)

Se o seu app já possui o token de um usuário que entrou pelo SSO, o mesmo endpoint responde pelo próprio usuário do token, sem 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" }'

A identidade vem exclusivamente do token verificado — não envie collaborators. Requisição com esse campo é rejeitada com SELF_MODE_NO_COLLABORATORS: token de usuário nunca consulta outras pessoas.
O escopo de empresa vem da sessão; a resposta tem exatamente o mesmo formato, com um único item em collaborators.
checkin_engagement funciona da mesma forma ({ "action": "checkin_engagement" }).
As actions de escrita e checkin_options são só para parceiros: com token de usuário, respondem 400 SELF_MODE_NOT_SUPPORTED. Dentro do app SalesOS, o check-in é feito pelo próprio app.

Use o modo self em telas renderizadas dentro do app autenticado; use a API key (S2S) quando o seu backend compõe telas antes de o usuário ter sessão no SalesOS — como um widget na Home de um superapp.

Tratamento de Erros

Todos os erros seguem a estrutura compartilhada:

{
  "error": {
    "code": "ERROR_CODE",
    "message": "Descrição legível",
    "details": []
  }
}

São dois formatos, não um. O bloco acima é o erro do endpoint. Falhas na camada de autenticação respondem antes de o endpoint rodar, com error como string:

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

Código que assume error.code lê undefined em toda falha de autenticação. Ramifique pelo tipo — veja Convenções da API.

400 — VALIDATION_ERROR

Body inválido, lote acima do limite, CPF sem 11 dígitos, ou item sem cpf nem email. O array details aponta o index do item.

401 — camada de autenticação

API key ausente, desconhecida ou expirada, ou assinatura não confere. A resposta traz error como string e códigos como header_missing, api_key_not_found, signature_invalid, timestamp_too_old.

403 — scope_insufficient

API key válida, mas sem o scope que a action exige (checkin:read, ou checkin:write para escrita). Quem responde é a camada de autenticação: { "error": "...", "code": "scope_insufficient", "missing_scopes": ["checkin:write"] }.

405 — METHOD_NOT_ALLOWED

Apenas POST é aceito.

429 — RATE_LIMITED

Escritas demais para o mesmo colaborador (10 em 10 minutos). Aguarde os segundos de Retry-After e tente de novo. As actions de escrita têm a própria tabela de erros em Registrando check-ins.

500 — SERVER_ERROR

Erro interno. Faça retry com backoff exponencial (2s, 4s, 8s).

Colaborador desconhecido não é erro. A requisição responde 200 com found: false naquele item — um CPF errado nunca quebra a renderização da Home inteira.

Rate Limits

Limite	Valor
Requisições por hora (padrão)	1000
Máx. colaboradores por `checkin_status`	500
Máx. colaboradores por `checkin_engagement`	100
Escritas por colaborador (`checkin_create` + `checkin_checkout`)	10 a cada 10 minutos

Segurança

Leitura exige checkin:read; criar ou encerrar check-in exige checkin:write — emita keys de escrita só para o backend dono do botão
Todo check-in criado pela API é guardado com a origem, a key que o criou, o seu client e a leitura de GPS original, para auditoria
Cada key é limitada a uma única empresa — CPF de outra empresa responde found: false
Requisições assinadas com HMAC (P2S-SIGN-V1) e logadas para auditoria; documentos nunca são escritos em logs

Nunca exponha a sua API key em código client-side. Esta API deve ser chamada apenas do seu backend.

Visão Geral

Integrações

API de Check-in

API de Check-in

Como funciona

Autenticação

Ambientes

Referência do Endpoint

Action: checkin_status

Schema da requisição

Exemplo

Campos da resposta

Trilha do dia (`include_day`)

Campos

Action: checkin_engagement

Exemplo

Registrando check-ins

Action: checkin_options

Action: checkin_create

Requisitos da localização

Action: checkin_checkout

Novas tentativas e `Idempotency-Key`

Mensagens para o corretor

Modo self (token do usuário do SSO)

Tratamento de Erros

Rate Limits

Segurança

Próximos passos

Autenticação

Suporte

​API de Check-in

​Como funciona

​Autenticação

​Ambientes

​Referência do Endpoint

​Action: checkin_status

​Schema da requisição

​Exemplo

​Campos da resposta

​Trilha do dia (include_day)

​Campos

​Action: checkin_engagement

​Exemplo

​Registrando check-ins

​Action: checkin_options

​Action: checkin_create

​Requisitos da localização

​Action: checkin_checkout

​Novas tentativas e Idempotency-Key

​Mensagens para o corretor

​Modo self (token do usuário do SSO)

​Tratamento de Erros

​Rate Limits

​Segurança

​Próximos passos

Autenticação

Suporte

API de Check-in

Como funciona

Autenticação

Ambientes

Referência do Endpoint

Action: checkin_status

Schema da requisição

Exemplo

Campos da resposta

Trilha do dia (`include_day`)

Campos

Action: checkin_engagement

Exemplo

Registrando check-ins

Action: checkin_options

Action: checkin_create

Requisitos da localização

Action: checkin_checkout

Novas tentativas e `Idempotency-Key`

Mensagens para o corretor

Modo self (token do usuário do SSO)

Tratamento de Erros

Rate Limits

Segurança

Próximos passos