Introdução
Bem-vindo à documentação da API Rubrix.
Nossa plataforma permite a orquestração completa de assinaturas digitais e eletrônicas, oferecendo suporte a algoritmos clássicos (RSA) e pós-quânticos (PQC — ML-DSA). A API está dividida nos seguintes módulos:
Fluxos (Flow) — Orquestração de múltiplos signatários com ordens de prioridade, quórum e notificações automáticas por e-mail.
Assinatura Direta (Sign) — Assinatura de documentos sob demanda utilizando sessões temporárias, sem necessidade de fluxo persistente.
Verificação (Verify) — Validação de integridade e conformidade de assinaturas em documentos PDF e XML.
Conceitos Principais
Tenants e Usuários
O Rubrix opera em um modelo multi-tenant. Cada organização possui um tenant que isola seus dados, fluxos e configurações.
Para criar um novo tenant, entre em contato com a equipe Rubrix. Ao registrar o tenant, você receberá acesso como Owner.
O gerenciamento de usuários (convites, atribuição de papéis e remoção) é feito pela interface web do Rubrix. Papéis disponíveis:
OWNER,ADMIN,USER.Um usuário pode pertencer a mais de um tenant e alternar entre eles via
POST /auth/switch-tenant.
Autenticação
A API oferece dois mecanismos de autenticação:
Bearer Token (JWT) — Obtido via
POST /auth/login. O token deve ser enviado no headerAuthorization: Bearer {token}. Possui tempo de expiração configurável (campoexpires_inna resposta).API Key — Criada via
POST /api-keys. Deve ser enviada no headerX-Api-Key: {apiKey}. Ideal para integrações de aplicação e automações. Não expira (a menos que uma data de expiração seja definida na criação).
Ambos os métodos são intercambiáveis — qualquer endpoint autenticado aceita tanto o JWT quanto a API Key.
Para testar se a autenticação está funcionando, utilize o endpoint GET /auth/me:
# Via API Key
curl --location 'https://rubrix.lat/core/api/auth/me' \
--header 'X-Api-Key: <SUA_API_KEY>'
# Via Bearer Token (JWT)
curl --location 'https://rubrix.lat/core/api/auth/me' \
--header 'Authorization: Bearer <SEU_TOKEN>'
Important
Todos os endpoints dos módulos de Flow e API Keys exigem autenticação (JWT ou API Key).
Os endpoints do módulo de Assinatura Direta (/provider/init, /sign/ready, /sign) não exigem autenticação no momento.
Tipos de Assinatura
O Rubrix suporta os seguintes tipos de assinatura digital:
Tipo |
Descrição |
|---|---|
|
Assinatura qualificada (certificado ICP-Brasil A1/A3). Maior valor jurídico. |
|
Assinatura avançada (certificado em nuvem com identificação forte do signatário). |
|
Assinatura simples/eletrônica. |
Perfis de Política de Assinatura
Ao assinar, é possível especificar o perfil de política (campo policyProfile):
Perfil |
Descrição |
|---|---|
|
Assinatura básica. Contém apenas o hash e a assinatura. |
|
Inclui carimbo de tempo (timestamp) confiável. |
|
Inclui dados para validação de longo prazo (certificados e CRLs). |
|
Inclui carimbo de tempo de arquivamento para validade estendida. |
Provedores
A plataforma integra com diversos provedores de identidade digital:
INTEGRAICP — Certificados ICP-Brasil (A1/A3).
PIXSIGN — Certificado efêmero emitido via pagamento Pix.
GOLDID — Provedor de identidade digital.
SAFEWEB — Provedor de certificados.
SERPRO — Provedor governamental.
Fluxo de Assinatura via Flow
O cliente inicia o fluxo via
POST /flow/init, enviando o documento em Base64 e a lista de pools de signatários.A API retorna um
flowId, o statusWAITINGe os links de assinatura para os signatários da prioridade atual.O sistema notifica os signatários por e-mail automaticamente.
Qualquer pessoa com o link de assinatura pode acessar o fluxo e assinar.
À medida que cada signatário assina (via
POST /flow/sign), o status é atualizado e o próximo pool é ativado.Após a conclusão de todas as assinaturas exigidas, a API envia um POST para a URL de webhook configurada, contendo o documento final assinado.
Note
O webhook recebe o binário do arquivo assinado com Content-Type: application/pdf (ou application/xml) e o header X-Flow-Id com o identificador do fluxo.
Fluxo de Assinatura Direta
A assinatura direta permite assinar um documento imediatamente, sem criar um fluxo persistente. O processo envolve iniciar uma sessão, autorizar a identidade e então assinar.
Descobrir identidades — O cliente envia o CPF ou CNPJ e o país (
BR) viaPOST /provider/init. A API retorna um array de identidades disponíveis, cada uma contendo umsessionIde umidentityEndpoint.Autorizar a identidade — O usuário escolhe uma das identidades retornadas e realiza a autorização:
Via OAuth: Utiliza o
identityEndpointretornado para autenticar-se no provedor de certificado digital.Via Pix: Utiliza
GET /pix/init/{sessionId}para gerar a cobrança eGET /pix/copiaCola/{sessionId}para obter o código Pix Copia e Cola. Ao efetuar o pagamento, o certificado efêmero é emitido automaticamente.
Aguardar sessão pronta — A aplicação monitora o status via
GET /sign/ready?sessionId={id}. A sessão só estará pronta (ready: true) após a conclusão bem-sucedida da autorização (OAuth ou pagamento Pix).Assinar — Com
ready: true, o documento é enviado paraPOST /signjunto com osessionId, e o binário assinado é retornado imediatamente na resposta.