Introdução Última atualização: 01/09/2026
Essa área é destinada para os desenvolvedores que desejam integrar o sDoc em seus sistemas.
Aqui você vai encontrar toda a referência técnica que precisa para realizar uma integração completa.
Exemplos
-
Postman
Baixe aqui a nossa Collection feita no Postman.
Histórico de atualizações
-
Versão 1.4
- Callback Completa (evento SolicitationCreated com participantes e arquivos)
-
Versão 1.3
- Perfis de Aprovador e Visualizador
- Notificação por WhatsApp e SMS (sujeito à habilitação da conta)
- Listar pastas da conta
-
Versão 1.2 beta
- Tipos de Assinatura (Digital e Eletrônica)
- Posicionamento de Carimbo
- Buscar Participante
-
Versão 1.0.2
- Correção de bugs
-
Versão 1.0.1
- Editar Solicitação
-
Versão 1.0
- Lançamento da API de integração
-
sDoc Integration 2020
Compatibilidade encerrada.
Tecnologias
-
.NET 10
Nossa API de integração foi feita inteiramente com .NET 10 usando C#. -
SQL Server
Nossa base de dados é 100% Microsoft com SQL Server. -
Windows Server (IIS)
A API está hospedada nos servidores seguros da Safeweb com Windows.
Recursos e Funcionalidades
Criar Solicitações
Criar fluxos de coletas de assinatura no sDoc via integração.
A API não realiza qualquer tipo de assinatura, esse processo é feito
inteiramente dentro do portal.
Contas
Gerencie as solicitações de sua empresa com o módulo de contas.
Válido somente para empresas que criaram a conta no portal.
Baixar Arquivo
Tenha acesso aos arquivos salvos em nuvem do sDoc.
Disponível somente para solicitações criadas via integração.
Callbacks
Seja notificado sempre que houver uma assinatura no arquivo.
A solicitação também pode aderir à Callback Completa,
que envia a situação de todos os participantes e arquivos do envelope a cada evento.
Recursos não contemplados
-
QR Code
O compartilhamento rápido de arquivos usando o QR Code não está disponível na Integração. -
Gestão da Conta
Nenhum recurso de gestão (ex. crias pastas / gerenciar usuários) é contemplado na integração. -
Consultar Solicitações
A Integração não suporta consultar a lista de solicitações criadas via portal ou integração.
Consultas são exclusivamente feitas pelo identificador único de cada uma.
Autenticação
Autenticação é feito pelo Header da requisição.
Como no exemplo abaixo, envie o Token no Header pela chave
Authorization.
Segurança do Token
-
O Token é exclusivo e intransferível.
Você fica inteiramente responsável pela guarda do token. -
O Token fica criptografado na nossa base de dados.
Somente você tem a versão original. -
A Safeweb não se responsabiliza pela perda ou vazamento do Token.
Caso ocorra essa adversidade, entre no portal do sDoc, no menu Integração e clique em Gerar Token.
Esse processo revoga o Token e a SecretKey geradas anteriormente.
Callbacks
Sempre que houver alguma notificação, o sDoc vai notificar seu sistema via callback cadastrado da plataforma ou vinculado a uma solicitação.
Notificações disponíveis
- Assinatura realizada Vamos notificar sempre que houver uma nova assinatura na sua solicitação.
Callback Completa
O formato descrito abaixo é o da notificação simples. Para receber a situação de todos os participantes e arquivos do envelope, consulte a seção Callback Completa.
SecretKey
Para garantir a segurança de sua API de callback, vamos enviar um SecretKey, que somente seu sistema e o sDoc conhecem, junto com a notificação.
Assim seu sistema sabe que é o sDoc chamando e notificando a atualização de uma solicitação.
-
Guarde a SecretKey dentro do seu código no back-end.
Assim você evita a exposição da SecretKey. -
A Safeweb não se responsabiliza pela perda ou vazamento da
SecretKey.
Caso ocorra essa adversidade, entre no portal do sDoc, no menu Integração e clique em Gerar Token.
Esse processo revoga o Token e a SecretKey geradas anteriormente.
Estrutura do conteúdo de resposta:
| Atributo | Tipo | Descrição | Tamanho |
|---|---|---|---|
| identifier | string | Identificador da solicitação. Identificador da solicitação que ocorreu uma alteração. | 30 |
| type | int | Tipo de notificação. Tipo de ação que ocorreu dentro da solicitação. Consulte a lista de enums para mais detalhes. | - |
| secretKey | string | SecretKey da plataforma. Chave para que sua aplicação saiba que é o sDoc chamando. | 130 |
Modelo JSON:
{
"identifier": "AAA000BBB111CCC222DDD333",
"type": 0,
"secretKey": "E35C7BE29087A8907136D9A0994CA96AF578C7A6F5CB94EF2D11D1BB83C1EDB3"
}
Callback Completa
A callback completa é um canal paralelo à notificação simples: a cada evento do fluxo,
enviamos um payload com o status da solicitação, quem realizou a ação e a
situação de todos os participantes e de todos os documentos do envelope.
A chamada é sempre um POST, com Content-Type: application/json; charset=utf-8.
Adesão
A adesão é explícita: envie "completeCallback": true no corpo da
criação da solicitação, junto com a URL em callback.
Além de true, aceitamos 1, sim, s,
yes, y e on (sem diferenciar maiúsculas).
Qualquer outro conteúdo — inclusive uma URL — não liga o canal.
A callback simples não muda
Quem já integra continua recebendo a notificação simples, no mesmo corpo e no mesmo evento (assinatura realizada). A callback completa é um canal adicional, e não uma substituição.
Eventos
São 9 eventos, um para cada etapa do ciclo de vida da solicitação — da criação até a conclusão, recusa ou exclusão.
| event | Descrição |
|---|---|
SolicitationCreated |
Solicitação criada via API e vinculada à plataforma integradora.
Primeiro disparo do ciclo; não parte de nenhum participante, então
participant é omitido e todos os participants[]
saem como pending.
|
queued |
Assinatura entrou em processamento — o participante concluiu a ação e o documento foi enfileirado. Estado transitório: não confirma a assinatura. |
signed |
Assinatura realizada com sucesso pelo participante em participant.
Único evento que a callback simples também emite.
|
approved |
Documento aprovado — o participante atua como aprovador, e não como signatário. Conta como assinatura processada para o fechamento da solicitação. |
rejected |
Assinatura recusada.
Leva a solicitação inteira para status: rejected, pois a recusa
interrompe o fluxo.
|
error |
Falha ao processar a assinatura.
Internamente a assinatura continua pendente, mas participante e arquivo
aparecem como error; cabe nova tentativa.
|
completed |
Solicitação concluída — todas as assinaturas foram processadas
(assinadas ou aprovadas).
Evento de envelope, sem participant.
|
deleted |
Solicitação excluída logicamente pelo portal.
Evento de envelope; o status vai para canceled.
|
participant_removed |
Participante removido do fluxo.
participant traz quem saiu; participants[] já vem sem ele.
|
Campos do payload
Raiz:
| Atributo | Tipo | Descrição |
|---|---|---|
| identifier | string | Identificador da solicitação na plataforma integradora. O mesmo que você já recebeu na criação da solicitação. |
| event | string | Evento que provocou o disparo. Domínio na tabela de eventos, acima. |
| status | string | Status da solicitação no instante do disparo, o mesmo que o sDoc mostra em tela. |
| date | string |
Data e hora do evento no formato yyyy-MM-dd HH:mm:ss.
Vai como texto, e não como data, para que o formato não dependa da
configuração do serializador.
|
| participant | objeto |
Quem realizou a ação: apenas identifier e email.
Omitido nos eventos de envelope (SolicitationCreated,
completed e deleted).
|
| participants | array | Todos os participantes do envelope com o status vigente no disparo, cada um com seus documentos. A ordem dos participantes é a de cadastro na solicitação. |
| secret_key | string |
Shared secret do token ativo da plataforma.
Vai no corpo para o receptor confirmar a origem sem depender do header
— essencial quando a estratégia de autenticação é None.
Omitido se a plataforma não tiver token ativo.
|
participants[]:
| Atributo | Tipo | Descrição |
|---|---|---|
| identifier | string | Identificador estável do participante. Sobrevive a uma eventual correção do e-mail na solicitação. |
| string | E-mail do participante. | |
| status | string |
Status do participante, consolidação de files[] — os dois
nunca divergem.
Não aparece dentro de participant, que leva só identificador
e e-mail.
|
| files | array |
Um item por assinatura que cabe ao participante.
Omitido quando ele ainda não tem nenhuma assinatura criada — e
também dentro de participant.
|
participants[].files[]:
| Atributo | Tipo | Descrição |
|---|---|---|
| identifier | string | Identificador do documento. |
| status | string | Status desta assinatura. Mesmo vocabulário do participante. |
Modelos JSON
Evento de participante (signed):
{
"identifier": "964C8DC5BB4342F19C3BA7FF5413A7",
"event": "signed",
"status": "in_progress",
"date": "2026-03-19 15:44:00",
"participant": {
"identifier": "9F2A1C34-7B0E-4D55-9E11-6C8A2D3F4B10",
"email": "joao@email.com"
},
"participants": [
{
"identifier": "9F2A1C34-7B0E-4D55-9E11-6C8A2D3F4B10",
"email": "joao@email.com",
"status": "signed",
"files": [
{ "identifier": "1A7C9D02-55E4-4B31-8F60-0D2E7A9C4411", "status": "signed" },
{ "identifier": "44B8E6F1-9C23-4A07-B5D8-7E1F30C6A922", "status": "signed" }
]
},
{
"identifier": "3B61D8AA-2E44-4C90-8A77-15D0B9E7C233",
"email": "maria@email.com",
"status": "pending",
"files": [
{ "identifier": "1A7C9D02-55E4-4B31-8F60-0D2E7A9C4411", "status": "pending" },
{ "identifier": "44B8E6F1-9C23-4A07-B5D8-7E1F30C6A922", "status": "pending" }
]
}
],
"secret_key": "b3f1c8d2-4a77-4f0e-9d51-2c9a6e18b7aa"
}
Evento de envelope (SolicitationCreated) — mesmo corpo, sem o bloco participant:
{
"identifier": "0CC7DB57FE62497F825B9212D43D10",
"event": "SolicitationCreated",
"status": "pending",
"date": "2026-08-19 10:24:23",
"participants": [
{
"identifier": "9F2A1C34-7B0E-4D55-9E11-6C8A2D3F4B10",
"email": "participante@dominio.com.br",
"status": "pending",
"files": [
{ "identifier": "1A7C9D02-55E4-4B31-8F60-0D2E7A9C4411", "status": "pending" },
{ "identifier": "44B8E6F1-9C23-4A07-B5D8-7E1F30C6A922", "status": "pending" }
]
}
],
"secret_key": "b3f1c8d2-4a77-4f0e-9d51-2c9a6e18b7aa"
}
Status da solicitação
O status da raiz é derivado do envelope inteiro, nesta ordem de precedência:
excluída → canceled; alguma recusa → rejected; todas
processadas → completed; alguma processada → in_progress;
senão → pending.
| Valor | Regra |
|---|---|
pending |
Nenhuma assinatura coletada ainda. |
in_progress |
Parte já assinou ou aprovou; faltam outros. |
completed |
Todas as assinaturas processadas (e há mais de zero). |
rejected |
Alguma assinatura recusada. |
canceled |
Solicitação excluída logicamente. |
Status do participante e do arquivo
| Valor | Significado |
|---|---|
pending |
Falta assinar algum documento, ou não há assinatura criada. |
signed |
Assinou todos os documentos que lhe cabiam. |
rejected |
Recusou algum documento. |
approved |
Aprovou todos os documentos — perfil aprovador. |
error |
A última tentativa de assinatura falhou. Vem da falha registrada na assinatura, e não do status interno, e tem precedência sobre ele. |
Reenvio
-
São feitas 2 tentativas, com intervalo de 10 segundos entre elas.
Somente falhas transitórias são repetidas (erro de rede, timeout, 5xx, 408 e 429). Respostas 4xx não são repetidas. -
Falhando as duas tentativas, o envio é descartado.
Não há reenvio automático posterior; o evento fica registrado nos nossos logs. -
Responda a chamada com HttpStatus 2xx o mais rápido possível.
Processe o payload de forma assíncrona no seu lado.
Enums
Status da Assinatura
| nº | Descrição |
|---|---|
| 1 | Pendente |
| 2 | Assinado |
| 3 | Rejeitado |
| 4 | Aprovado |
Tipo de Assinatura
| nº | Descrição |
|---|---|
| 1 | Assinatura Digital. |
| 2 | Assinatura Eletrônica. |
| 3 | Aprovador. |
| 4 | Visualizador. |
Tipo de Notificação
| nº | Descrição |
|---|---|
| 1 | Assinatura realizada. |
| 2 | Assinatura rejeitada. [ Não implementado ] |
| 3 | Solicitação editada no portal. [ Não implementado ] |
| 4 | Solicitação excluida via portal. [ Não implementado ] |
| 5 | Download de arquivo via portal. [ Não implementado ] |