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

# Seguridad y confiabilidad

> Descubra cómo Notifique previene duplicados, pérdida de mensajes y fugas de datos.

<Tip>
  Notifique es el **portero** entre su código y el cliente: evita cargos dobles, no permite que los mensajes desaparezcan en pleno vuelo y mantiene cada espacio de trabajo aislado de los demás.
</Tip>

## ¿Qué es?

Es el conjunto de protecciones que hace que cada envío sea **único**, **rastreable** y **seguro**. Se integra una vez; la plataforma maneja lo que sucede después de que la API acepta la solicitud.

Piense en un edificio con recepción: su código entrega el paquete en la recepción; Notifique gestiona la cola, evita entregar dos veces y registra lo sucedido.

## ¿Contra qué protege Notifique?

| Riesgo                             | Cómo lo prevenimos                       |
| ---------------------------------- | ---------------------------------------- |
| **Envíos duplicados**              | Encabezado `Idempotency-Key` (24 h)      |
| **Mensajes perdidos**              | Colas, bloqueos y reintentos automáticos |
| **Filtraciones entre clientes**    | Aislamiento por espacio de trabajo       |
| **Datos sensibles en logs**        | Redacción automática (`[REDACTED]`)      |
| **Claves o webhooks falsificados** | Hash de Clave API + firma HMAC           |

## Evite envíos duplicados

¿Hubo error de conexión, timeout y su sistema reintentó? En integraciones ingenuas, al cliente se le cobra **dos veces**.

En Notifique, envíe un identificador único en el encabezado **`Idempotency-Key`** (también aceptamos `X-Idempotency-Key`):

1. Genere una clave **por operación** (por ejemplo, ID de pedido, hash de carga útil)
2. Envíela en el encabezado de cada POST crítico
3. Si repite la **misma clave** dentro de **24 h**, la API **no crea otro mensaje**
4. La respuesta devuelta proviene de la **primera** solicitud aceptada

| Situación                                      | ¿Usar `Idempotency-Key`?            |
| ---------------------------------------------- | ----------------------------------- |
| Facturación, OTP, confirmación de pedido       | **Sí**                              |
| Envío masivo con su propio ID por destinatario | **Sí** (una clave por destinatario) |
| Consultas GET (listar, obtener estado)         | No es necesario                     |

<Note>
  Reintente cuantas veces necesite. El destinatario recibe **una vez**.
</Note>

## Nada se pierde en tránsito

El servidor se reinicia, WhatsApp se tambalea y la cola no está disponible un momento. En sistemas frágiles, el mensaje desaparece. Aquí, cada paso tiene red de seguridad:

| Mecanismo            | Qué hace                                                       |
| -------------------- | -------------------------------------------------------------- |
| **Colas**            | Cada mensaje entra en una cola ordenada por espacio de trabajo |
| **Bloqueos**         | El mismo mensaje no se procesa dos veces a la vez              |
| **Reintentos**       | ¿Fallo temporal? Reintentamos con intervalos crecientes        |
| **Webhook de fallo** | ¿Fallo permanente (número inválido)? Recibe el evento          |

Como la **línea de correos**: un paquete a la vez, en orden, con registro si algo sale mal.

Para resultados finales, combine **webhooks** (estado de entrega) con [logs de API](/es/guides/logs/index) (si se aceptó la solicitud HTTP).

## Sus datos y los de sus clientes

| Tema             | Cómo lo protegemos                                                                                                                                    |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Aislamiento**  | Cada espacio de trabajo es separado. Un cliente no accede a datos de otro                                                                             |
| **Trust Factor** | Puntuación de reputación por espacio de trabajo; niveles amarillo/rojo limitan envíos diarios. Ver [Trust Factor](/es/guides/workspaces/trust-factor) |
| **Logs**         | Tokens y datos sensibles pasan a `[REDACTED]` antes del almacenamiento                                                                                |
| **Claves API**   | Almacenadas como hash, nunca en texto plano                                                                                                           |
| **Webhooks**     | Firma HMAC (`X-Notifique-Signature`). Valide en su servidor                                                                                           |
| **Ámbitos**      | Cada clave abre solo lo necesario. Ver [Claves API](/es/guides/api-key/index#ámbitos-y-permisos)                                                      |

Informes de destinatarios (Ley brasileña 14.230/2021): [API de denuncias (FELCA)](/es/guides/compliance/report-api).

## Qué hacer de su lado

1. **Nunca** confirme claves API. Utilice `.env` o una bóveda de secretos
2. Utilice **`Idempotency-Key`** en envíos críticos (facturación, OTP, confirmación)
3. Responda **2xx** rápidamente en webhooks y procese en segundo plano
4. **Valide** la firma HMAC en cada webhook. Consulte [Webhooks](/es/guides/webhooks/index#encabezados-y-firma)
5. Observe **402** y **403**. A menudo hay límites o ámbitos, no errores de código
6. Pruebe en [Sandbox](/es/guides/sandbox/index) antes de pasar a producción

***

## Próximos pasos

* [Claves API](/es/guides/api-key/index): ámbitos, rotación y límites por clave
* [Webhooks](/es/guides/webhooks/index): configurar URL y validar firma
* [Respuestas de error](/es/guides/conceitos/resposta-de-erros): códigos HTTP y `code`
* [Trust Factor](/es/guides/workspaces/trust-factor): reputación y límites de envío
* [Sandbox](/es/guides/sandbox/index): integrar sin riesgo de producción