> ## Documentation Index
> Fetch the complete documentation index at: https://docs.notifique.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Segurança e Confiabilidade

> Aprenda como a Notifique evita duplicata, perda de mensagens e vazamento de dados.

<Tip>
  A Notifique é o **porteiro** entre o seu código e o cliente: evita cobrança duplicada, não deixa mensagem sumir no caminho e mantém cada workspace isolado dos outros.
</Tip>

## O que é?

É o conjunto de proteções que garante que cada envio seja **único**, **rastreável** e **seguro**. Você integra uma vez; a plataforma cuida do que acontece depois que a API aceita a requisição.

Pense num prédio com portaria: seu código entrega o pacote na recepção; a Notifique organiza a fila, evita entregar duas vezes e registra o que aconteceu.

## O que a Notifique protege?

| Risco                            | Como evitamos                            |
| -------------------------------- | ---------------------------------------- |
| **Envio duplicado**              | Header `Idempotency-Key` (24 h)          |
| **Mensagem perdida**             | Filas, travas e retentativas automáticas |
| **Vazamento entre clientes**     | Isolamento por workspace                 |
| **Dados sensíveis em log**       | Redação automática (`[REDACTED]`)        |
| **Chave ou webhook falsificado** | Hash de API Keys + assinatura HMAC       |

## Evite envio duplicado

Internet oscilou, deu timeout e seu sistema tentou de novo? Em integrações simples, o cliente recebe a cobrança **duas vezes**.

Na Notifique, envie um identificador único no header **`Idempotency-Key`** (também aceitamos `X-Idempotency-Key`):

1. Gere uma chave **por operação** (ex.: ID do pedido, hash do payload)
2. Envie no header em cada POST crítico
3. Se repetir a **mesma chave** em até **24 h**, a API **não cria outra mensagem**
4. A resposta devolvida é a da **primeira** requisição aceita

| Situação                                       | Usar `Idempotency-Key`?              |
| ---------------------------------------------- | ------------------------------------ |
| Cobrança, OTP, confirmação de pedido           | **Sim**                              |
| Envio em massa com ID próprio por destinatário | **Sim** (uma chave por destinatário) |
| Consultas GET (listar, buscar status)          | Não precisa                          |

<Note>
  Pode tentar de novo quantas vezes precisar. O destinatário recebe **uma vez**.
</Note>

## Nada se perde no caminho

Servidor reinicia, WhatsApp oscila, fila fica indisponível por um instante. Em sistemas frágeis, a mensagem some. Aqui, cada etapa tem rede de segurança:

| Mecanismo            | O que faz                                                    |
| -------------------- | ------------------------------------------------------------ |
| **Filas**            | Cada mensagem entra numa fila ordenada por workspace         |
| **Travas**           | A mesma mensagem não é processada duas vezes ao mesmo tempo  |
| **Retentativas**     | Falha temporária? Tentamos de novo com intervalos crescentes |
| **Webhook de falha** | Falha definitiva (número inválido)? Você recebe o evento     |

É como a **fila do correio**: um pacote por vez, na ordem, com registro se algo der errado.

Para o resultado final, combine **webhooks** (status de entrega) com [Logs da API](/guides/logs/index) (se a requisição HTTP foi aceita).

## Seus dados e os do cliente

| Tópico           | Como protegemos                                                                                                                           |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| **Isolamento**   | Cada workspace é separado. Um cliente não acessa dados de outro                                                                           |
| **Trust Factor** | Pontuação de reputação por workspace; tiers amarelo/vermelho limitam envios diários. Veja [Trust Factor](/guides/workspaces/trust-factor) |
| **Logs**         | Tokens e dados sensíveis viram `[REDACTED]` antes de salvar                                                                               |
| **API Keys**     | Guardadas como hash, nunca em texto puro                                                                                                  |
| **Webhooks**     | Assinatura HMAC (`X-Notifique-Signature`). Valide no seu servidor                                                                         |
| **Escopos**      | Cada chave abre só o que precisa. Veja [Chaves de API](/guides/api-key/index#escopos-e-permissões)                                        |

Denúncias de destinatários (Lei 14.230/2021): [API de denúncias (FELCA)](/guides/compliance/report-api).

## O que fazer no seu lado

1. **Nunca** commite API Key. Use `.env` ou cofre de segredos
2. Use **`Idempotency-Key`** em envios críticos (cobrança, OTP, confirmação)
3. Responda **2xx rápido** nos webhooks e processe em background
4. **Valide** a assinatura HMAC de cada webhook. Veja [Webhooks](/guides/webhooks/index#headers-e-assinatura)
5. Monitore **402** e **403**. Muitas vezes são limite ou escopo, não bug de código
6. Teste no [Sandbox](/guides/sandbox/index) antes de ir para produção

***

## Próximos passos

* [Chaves de API](/guides/api-key/index): escopos, rotação e limites por chave
* [Webhooks](/guides/webhooks/index): configurar URL e validar assinatura
* [Respostas de erro](/guides/conceitos/resposta-de-erros): códigos HTTP e `code`
* [Trust Factor](/guides/workspaces/trust-factor): reputação e limites de envio
* [Sandbox](/guides/sandbox/index): integrar sem risco em produção