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

# Webhook personalizado: enviar leads entrantes a DeltaLead

> Enviar leads a DeltaLead desde cualquier sistema externo con una sola solicitud POST autenticada: crear una clave, probar en sandbox y pasar a live.

El Webhook personalizado es la vía por la que un sistema externo envía un lead **hacia** DeltaLead. Una landing page, el sistema de gestión del concesionario, el feed de leads de un socio o un script interno hacen una única solicitud `POST` autenticada y el lead queda registrado en la cuenta. Esta es la dirección entrante, lo contrario de [Webhooks y Zapier](/integrations/webhooks-zapier), que envía eventos desde DeltaLead hacia un endpoint externo.

## Cómo funciona

Hay una sola ruta y hace una sola cosa:

```text theme={null}
POST https://integrations.deltalead.ai/webhooks/custom
```

La autenticación usa una clave creada en el panel, enviada como bearer token:

```text theme={null}
Authorization: Bearer dl_sandbox_YOUR_KEY
```

Esa clave es toda la identidad de la solicitud: le indica a DeltaLead a qué cuenta pertenece el lead y si la entrega es `live` o `sandbox`. No hay ID de cuenta, ID de organización ni ID de endpoint en ninguna parte de la URL: la URL es la misma para todos los clientes.

## Crear una clave

<Steps>
  <Step title="Abrir la configuración del Webhook personalizado">
    En el panel de DeltaLead, ir a **Configuración → Integraciones → Custom Webhook**.
  </Step>

  <Step title="Elegir live o sandbox">
    El modo se define al crear la clave y queda fijo durante toda su vida; para cambiarlo hay que crear una segunda clave. La mayoría de las integraciones mantienen una de cada tipo.
  </Step>

  <Step title="Agregar una etiqueta y un vencimiento opcionales">
    La etiqueta ayuda a distinguir las claves más adelante, por ejemplo `web-form-prod`. El vencimiento es opcional y puede fijarse entre 1 y 365 días; sin él, la clave no vence por sí sola.
  </Step>

  <Step title="Copiar la clave">
    La clave completa se muestra una sola vez, al crearla. Debe guardarse en el gestor de secretos de la aplicación antes de cerrar el diálogo.
  </Step>
</Steps>

<Warning>
  La clave en texto plano se muestra **exactamente una vez**, en el momento de crearla. DeltaLead solo almacena un hash SHA-256 y no puede volver a mostrarla. Si una clave se pierde, la única salida es rotarla: no hay recuperación.
</Warning>

## Gestión de claves

La lista de claves muestra todas las claves de la cuenta:

| Columna        | Qué indica                                                                                            |
| -------------- | ----------------------------------------------------------------------------------------------------- |
| `key_prefix`   | Los primeros caracteres de la clave, suficientes para identificar cuál usa cada sistema sin revelarla |
| Modo           | `live` o `sandbox`                                                                                    |
| Estado         | Activa, revocada o vencida                                                                            |
| Creada / Vence | Cuándo se emitió la clave y cuándo deja de funcionar                                                  |
| `last_used_at` | La última vez que una solicitud se autenticó con esta clave                                           |

<Tip>
  `last_used_at` es la forma más rápida de confirmar que una integración está realmente conectada. Al enviar una solicitud de prueba, si la marca de tiempo no se mueve es porque el cliente no está llegando a DeltaLead con esa clave.
</Tip>

Sobre una clave existente hay dos acciones disponibles:

* **Rotar** — emite un secreto nuevo y conserva el modo y la etiqueta de la clave. Sirve cuando una clave pudo haberse filtrado o cuando la rotación de secretos es periódica. El secreto anterior deja de funcionar de inmediato, así que primero conviene desplegar el nuevo.
* **Revocar** — deshabilita la clave de forma permanente. No se puede deshacer: una clave revocada nunca se reactiva.

Las claves se crean y se gestionan en el panel. No hay una API pública para emitirlas ni revocarlas.

## Claves live y sandbox

`live` y `sandbox` son **modos de clave, no sistemas separados**. Ambos se sirven desde el mismo host y la misma ruta indicada arriba. Probar con una clave sandbox implica llamar a producción: es intencional, y significa que la integración verificada es exactamente la misma que después se pone en marcha.

Lo que cambia es qué pasa con el lead una vez que llega:

|                                                                       | `live`                  | `sandbox`                                   |
| --------------------------------------------------------------------- | ----------------------- | ------------------------------------------- |
| El lead se almacena                                                   | Sí, de forma permanente | Sí, en un almacén aislado                   |
| Visible en el Inbox unificado                                         | Sí                      | No                                          |
| Retención                                                             | Permanente              | Se purga solo, a los 7 días aproximadamente |
| Automatizaciones posteriores (Resumen de IA, scoring, notificaciones) | Se ejecutan             | No se ejecutan                              |

<Note>
  Lo recomendable es construir y verificar la integración con una clave sandbox y después cambiarla por una live. Nada más de la solicitud cambia: misma URL, mismos headers, mismo body. Las entregas de sandbox nunca llegan al equipo comercial y se limpian solas.
</Note>

<Warning>
  Hay algo que **no** está aislado por modo: los valores de `Idempotency-Key` se registran por cuenta, no por modo de clave. Un valor ya enviado con una clave sandbox se considera repetido cuando después llega con una clave live, y esa entrega live devuelve `duplicate` sin crear el lead. Conviene usar valores distintos durante las pruebas —con un prefijo, por ejemplo— o generar valores nuevos al pasar a live.
</Warning>

## Enviar el primer lead

<Steps>
  <Step title="Crear una clave sandbox">
    Seguir los pasos anteriores y copiar la clave en texto plano.
  </Step>

  <Step title="Enviar el body mínimo válido">
    Un lead necesita un nombre y, además, al menos un email o un teléfono.

    ```bash cURL theme={null}
    curl -X POST https://integrations.deltalead.ai/webhooks/custom \
      -H "Authorization: Bearer dl_sandbox_YOUR_KEY" \
      -H "Content-Type: application/json" \
      -d '{"lead":{"name":"María García","email":"maria@example.com"}}'
    ```
  </Step>

  <Step title="Leer la respuesta">
    Una entrega aceptada por DeltaLead devuelve:

    ```json 200 OK theme={null}
    {"status":"ok"}
    ```

    Cualquier otro estado significa que la entrega no fue aceptada; ver la [referencia completa de respuestas](/api-reference/webhooks/custom-inbound#responses).
  </Step>

  <Step title="Esperar unos segundos">
    La respuesta es sincrónica, pero confirma la *aceptación*, no la creación. DeltaLead encola la entrega y crea el lead unos segundos después. Por eso un `200` no significa que el lead ya exista: significa que va a existir.
  </Step>

  <Step title="Repetir con una clave live">
    Enviar la misma solicitud con una clave live y abrir el Inbox unificado. El lead aparece ahí, recibe un score y dispara las automatizaciones configuradas. El lead de sandbox no está en el Inbox, y nunca va a estarlo.
  </Step>
</Steps>

## Próximos pasos

<CardGroup cols={2}>
  <Card title="Referencia del endpoint" icon="code" href="/api-reference/webhooks/custom-inbound">
    El contrato completo del lead, la idempotencia, los límites de tasa y todos los códigos de respuesta.
  </Card>

  <Card title="Webhooks salientes" icon="webhook" href="/integrations/webhooks-zapier">
    La otra dirección: recibir eventos de leads enviados desde DeltaLead a un endpoint externo.
  </Card>
</CardGroup>
