> ## 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.

# Security and reliability

> Learn how Notifique prevents duplicates, message loss, and data leaks.

<Tip>
  Notifique is the **doorman** between your code and the customer: it prevents double charges, does not let messages vanish mid-flight, and keeps each workspace isolated from others.
</Tip>

## What is it?

It's the set of protections that make every send **unique**, **traceable**, and **secure**. You integrate once; the platform handles what happens after the API accepts the request.

Think of a building with a front desk: your code drops off the package at reception; Notifique manages the queue, avoids delivering twice, and records what happened.

## What does Notifique protect against?

| Risk                        | How we prevent it                    |
| --------------------------- | ------------------------------------ |
| **Duplicate sends**         | `Idempotency-Key` header (24 h)      |
| **Lost messages**           | Queues, locks, and automatic retries |
| **Cross-customer leaks**    | Per-workspace isolation              |
| **Sensitive data in logs**  | Automatic redaction (`[REDACTED]`)   |
| **Forged keys or webhooks** | API Key hashing + HMAC signature     |

## Avoid duplicate sends

Connection blipped, timeout fired, and your system retried? In naive integrations, the customer gets charged **twice**.

On Notifique, send a unique identifier in the **`Idempotency-Key`** header (we also accept `X-Idempotency-Key`):

1. Generate one key **per operation** (e.g. order ID, payload hash)
2. Send it in the header on every critical POST
3. If you repeat the **same key** within **24 h**, the API **does not create another message**
4. The response returned is from the **first** accepted request

| Situation                                | Use `Idempotency-Key`?          |
| ---------------------------------------- | ------------------------------- |
| Billing, OTP, order confirmation         | **Yes**                         |
| Bulk send with your own ID per recipient | **Yes** (one key per recipient) |
| GET queries (list, fetch status)         | Not needed                      |

<Note>
  Retry as much as you need. The recipient receives **once**.
</Note>

## Nothing gets lost in transit

Server restarts, WhatsApp wobbles, queue briefly unavailable. On fragile systems, the message disappears. Here, each step has a safety net:

| Mechanism           | What it does                                          |
| ------------------- | ----------------------------------------------------- |
| **Queues**          | Each message enters an ordered queue per workspace    |
| **Locks**           | The same message is not processed twice at once       |
| **Retries**         | Temporary failure? We retry with increasing intervals |
| **Failure webhook** | Permanent failure (invalid number)? You get the event |

Like the **post office line**: one package at a time, in order, with a record if something goes wrong.

For final outcomes, combine **webhooks** (delivery status) with [API logs](/guides/logs/index) (whether the HTTP request was accepted).

## Your data and customer data

| Topic            | How we protect it                                                                                                              |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Isolation**    | Each workspace is separate. One customer cannot access another's data                                                          |
| **Trust Factor** | Per-workspace reputation score; yellow/red tiers cap daily outbound sends. See [Trust Factor](/guides/workspaces/trust-factor) |
| **Logs**         | Tokens and sensitive data become `[REDACTED]` before storage                                                                   |
| **API Keys**     | Stored as hash, never plain text                                                                                               |
| **Webhooks**     | HMAC signature (`X-Notifique-Signature`). Validate on your server                                                              |
| **Scopes**       | Each key opens only what it needs. See [API Keys](/guides/api-key/index#scopes-and-permissions)                                |

Recipient reports (Brazilian Law 14.230/2021): [Report API (FELCA)](/guides/compliance/report-api).

## What to do on your side

1. **Never** commit API Keys. Use `.env` or a secrets vault
2. Use **`Idempotency-Key`** on critical sends (billing, OTP, confirmation)
3. Respond **2xx** quickly on webhooks and process in the background
4. **Validate** HMAC signature on every webhook. See [Webhooks](/guides/webhooks/index#headers-and-signature)
5. Watch **402** and **403**. Often limits or scopes, not code bugs
6. Test in [Sandbox](/guides/sandbox/index) before going to production

***

## Next steps

* [API Keys](/guides/api-key/index): scopes, rotation, and per-key limits
* [Webhooks](/guides/webhooks/index): set up URL and validate signature
* [Error responses](/guides/conceitos/resposta-de-erros): HTTP codes and `code`
* [Trust Factor](/guides/workspaces/trust-factor): reputation and send limits
* [Sandbox](/guides/sandbox/index): integrate without production risk