CLP SISTEMASTermos e privacidade

Integre ao login do seu sistema

API REST autenticada por aplicação. Cadastre a empresa, confirme o pagamento e crie uma aplicação no painel. Guarde as duas chaves no backend, nunca no navegador do usuário final.

1. Avaliar um acesso

Use a chave de avaliação em Authorization: Bearer SUA_CHAVE, JSON e um Idempotency-Key exclusivo por evento. A base é a mesma origem deste painel.

POST /v1/access/evaluations
Authorization: Bearer SUA_CHAVE
Idempotency-Key: evento_00000001
Content-Type: application/json

{
  "subject_id": "usuario_0001",
  "session_id": "sessao_00001",
  "device_id": "dispositivo_0001",
  "action": "view_dashboard",
  "primary_authenticated": true,
  "authenticated_at": "2026-09-29T10:00:00Z",
  "authentication_method": "passkey"
}

O horário acima é ilustrativo: envie o instante real da autenticação verificada pelo seu servidor. Identificadores e idempotência: 8–128 caracteres ASCII, letras minúsculas (a–z), números, traço ou sublinhado. Gere pseudônimos canônicos, como hashes hexadecimais minúsculos; não transforme IDs distintos do seu sistema em um mesmo pseudônimo. Não envie dados pessoais diretos ou segredos. O identificador do dispositivo deve ser vinculado à sessão pelo backend, não aceito cegamente do navegador.

Ações: view_dashboard, view_account, login, failed_login, change_bank_account, account_recovery, enroll_factor, payment. Métodos: password, email_otp, sms_otp, totp, passkey. Para falha de login, use primary_authenticated: false, com horário e método nulos. O serviço não executa nem verifica o desafio do seu provedor.

2. Interpretar a resposta

recommended_action: continue_existing_session, require_step_up, review ou deny. A resposta inclui decision_id, mode, enforceable, reason_codes, signal_quality, policy_version, evaluated_at, expires_at, app_id, subject_id, session_id, device_id, action, allowed_methods.

Observação (shadow) nunca dispensa o desafio atual. Ative a política pelo painel depois de testar sua integração. Em modo ativo, a continuidade exige dispositivo confiável e autenticação recente com passkey ou TOTP; isso não equivale a uma probabilidade de fraude. TOTP não oferece a mesma resistência a phishing que passkeys. Ações sensíveis sempre exigem confirmação adicional. Cinco falhas em 15 minutos resultam em recusa recomendada.

3. Consumir uma decisão ativa

Antes de aplicá-la, envie o mesmo contexto e um identificador exclusivo da operação. Uma decisão não pode ser usada em outra operação. O ERP deve executar a operação também de forma idempotente usando este identificador.

POST /v1/access/evaluations/DECISION_ID/consume
Authorization: Bearer SUA_CHAVE
Content-Type: application/json

{
  "subject_id": "usuario_0001",
  "session_id": "sessao_00001",
  "device_id": "dispositivo_0001",
  "action": "view_dashboard",
  "operation_id": "operacao_00000001"
}

Consumo aceita apenas decisão ativa, válida e da versão atual. Repetir o mesmo consumo é idempotente. Mudar contexto, operação ou política, revogar o dispositivo ou ultrapassar a validade pode gerar 409. A validade máxima é 60 segundos, limitada pelo prazo da autenticação. O campo enforceable não significa “acesso autorizado”: aplique a recomendação retornada.

4. Dispositivos e feedback

Após verificação forte recente no seu backend, use a chave administrativa para POST /v1/admin/devices com subject_id, device_id, verification_method, verified_at. São aceitos passkey/TOTP verificados nos últimos cinco minutos. A confiança dura 30 dias. Revogue por DELETE /v1/admin/devices/{subject}/{device}. A chave de avaliação não pode criar confiança.

Envie POST /v1/access/evaluations/{id}/feedback com {"outcome":"challenge_passed"}. Outros resultados: challenge_failed, confirmed_compromise, confirmed_legitimate, unknown. Resultados confirmados exigem chave administrativa. O primeiro feedback é imutável; repetição igual é aceita. Feedback nunca cria confiança. Desafio aprovado não comprova legitimidade.

5. Consultas, limites e falhas

Avaliação nova: 201. Mesma idempotência e mesmo corpo: 200 com a decisão original, sem renovar validade ou consumir de novo. Corpo diferente: 409. Após 30 dias, replay retorna 410; identificadores de idempotência ficam protegidos por até 90 dias. Não reutilize chaves antigas.

20.000 avaliações por mês de calendário UTC, compartilhadas entre até três aplicações. 120 requisições/minuto por aplicação. 16 KB por corpo. Campos desconhecidos são rejeitados. 400: entrada inválida; 401: chave ausente, inválida, revogada, vencida ou conta sem vigência; 403: permissão; 404: recurso não encontrado neste escopo; 409: conflito; 413: corpo grande; 429: limite; 5xx: indisponibilidade. Nunca converta erro, timeout ou resultado vencido em baixo risco. Preserve a autenticação habitual e recuse ações sensíveis se o fallback não puder ser aplicado.

Na rotação pelo painel, a chave anterior é revogada imediatamente. Cada chave vale até um ano. A desativação da aplicação revoga ambas as chaves. Não envie chaves em URLs, logs, telas ou chamados.

6. Relatórios com IA

Solicitados no painel, com quatro requisições aceitas/mês por empresa e mínimo de dez avaliações. Apenas contagens de recomendações e resultados seguem ao Gemini. A análise é assíncrona, pode falhar e não altera a política. Consulte novamente o painel para acompanhar. Não inclua dados de usuários em nomes de aplicações ou chamados.

7. Operação

Confirme autenticação do seu backend, isolamento por aplicação, requisições concorrentes, fallback, revogação e reversão de política antes de ativar. O modo ativo é uma política de regras, não um modelo estatístico antifraude calibrado. Não há SLA individual nesta oferta. Para suporte: contato@clpsistemas.com.br.