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

# Cómo funciona el enrutamiento

> Cómo JD Courier decide qué motor recibe cada mensaje SPB y Pix, y qué pasa con un mensaje que no puede enrutar o entregar.

El Courier decide una cosa para cada mensaje que JD envía a tu institución: qué motor lo recibe. Esta página explica el mapa de titularidad, las reglas de enrutamiento de cada riel y la retención de los mensajes que el Courier no puede enrutar o entregar.

## El mapa de titularidad

***

El mapa de titularidad es una lista de claves. Cada clave tiene un motor dueño. Un operador crea y cambia el mapa a través de la [API de titularidad](/es/reference/interfaces/jd-courier/assign-a-key-to-an-engine). El Courier rechaza un segundo dueño para una clave con `409 JDC-0102`. Para cambiar el dueño, el operador [mueve la clave](/es/reference/interfaces/jd-courier/move-a-key-to-another-engine).

El mapa acepta siete tipos de clave:

| Tipo de clave | Qué identifica | Usado por el enrutamiento entrante |
| - | - | - |
| `ACCOUNT` | Una cuenta, como agencia y número de cuenta. Una cuenta de pago no tiene agencia. | Sí, en SPB y en Pix |
| `DOCUMENT` | Un CPF o un CNPJ. | Sí, en Pix Automático, para el CNPJ del cobrador |
| `PIX_RECURRENCE_ID` | Una recurrencia de Pix Automático. | Sí, en Pix Automático |
| `PIX_KEY_EMAIL` | Una clave Pix de email. | No |
| `PIX_KEY_PHONE` | Una clave Pix de teléfono, en formato E.164. | No |
| `PIX_KEY_RANDOM` | Una clave Pix aleatoria. | No |
| `PAYMENT_ID` | Un identificador de pago. | No |

Los tipos que el enrutamiento entrante no usa están disponibles para los motores a través de la [consulta de titularidad](/es/reference/interfaces/jd-courier/resolve-which-engine-owns-a-key). Un motor usa la consulta para saber si otro motor es dueño del destino de un pago.

El Courier normaliza cada valor de clave. Por ejemplo, quita la puntuación de un CPF y los ceros a la izquierda de una agencia. Envía el valor como lo guardas.

Cada cambio en el mapa escribe una entrada en el historial de auditoría de la clave, en la misma transacción. La entrada registra quién hizo el cambio, cuándo, el dueño anterior y el nuevo dueño. Un movimiento también registra su motivo. Puedes leer el historial de una clave después de su eliminación, a través de la [consulta de auditoría por clave](/es/reference/interfaces/jd-courier/ownership-history-for-one-key-addressed-by-the-key).

## Enrutamiento en el riel SPB

***

El rol `spb-consumer` lee los mensajes SPB que JD guarda para tu institución. El Courier guarda cada mensaje antes de decidir la ruta. Después, aplica estas reglas, en orden:

1. **Registro de envíos.** Cuando el número de control (`NumCtrlIF`) del mensaje coincide con un envío del [registro de envíos](#sends-to-jd-and-the-send-journal), el mensaje va al motor que hizo el envío. Esta regla enruta las respuestas a los mensajes que un motor envió.
2. **Mapa de titularidad.** El Courier lee la cuenta acreditada del mensaje: agencia y cuenta, o la cuenta de pago. Cuando el mapa tiene un dueño para esa cuenta, el mensaje va al dueño.
3. **Modo de entrega.** Cuando el mapa no tiene dueño, el Courier lee el [modo de entrega](#delivery-modes) declarado para el código del mensaje. Esta regla nunca se aplica a los códigos de dinero `STR0008`, `STR0008R1`, `STR0008R2`, `STR0010`, `STR0010R1` y `STR0010R2`.
4. **Retención.** Cuando ninguna regla decide, el Courier [retiene](#retained-messages) el mensaje.

El motor debe estar habilitado. Cuando la regla 1 o la regla 2 nombra un motor deshabilitado, el Courier retiene el mensaje con el motivo `DELIVERY_FAILED`.

El Courier no empuja mensajes SPB a los motores. Cada motor le pide sus mensajes al Courier por la misma interfaz SOAP que usa con JD. El Courier responde con el mensaje más antiguo que espera a ese motor. Para los detalles, consulta [Conectar un motor](/es/interfaces/jd-courier/jd-courier-engine-integration).

<h3 id="delivery-modes">
  Modos de entrega
</h3>

Un modo de entrega se aplica a un código de mensaje SPB. Un operador [lo declara](/es/reference/interfaces/jd-courier/declare-the-delivery-mode-for-one-message-code) con un motivo. Hay dos modos:

* `ALL_ENGINES`: el mensaje va a cada motor habilitado.
* `REFUSE`: el mensaje no va a ningún motor. El Courier lo guarda, con el estado `REFUSED`.

Un código sin declaración sigue el valor predeterminado: un dueño. El Courier rechaza una declaración para un código de dinero con `422 JDC-0110`. Una declaración revocada sigue legible como historial. El riel Pix no acepta declaraciones.

### Reentrega

Un operador puede [servir de nuevo un mensaje SPB](/es/reference/interfaces/jd-courier/reopen-the-delivery-of-a-message-to-an-engine) a uno de los motores a los que se enrutó el mensaje. El Courier no le pregunta de nuevo a JD. La siguiente solicitud del motor recibe el mensaje guardado, con su número de secuencia original. Tu operador da un motivo, y el Courier lo registra.

### Bypass

Un bypass es el estado en el que un motor se conecta de nuevo a JD directamente, fuera del Courier. Un operador declara un bypass en el riel SPB con el motor y un motivo.

Mientras un bypass está activo, el Courier no lee de JD en ese riel. Tampoco enruta ni verifica de nuevo los mensajes SPB. Un ciclo de conciliación que se ejecuta durante un bypass lista las garantías suspendidas. Como máximo un motor puede estar en bypass en un riel. El riel Pix no tiene bypass.

## Enrutamiento en el riel Pix

***

JD envía las llamadas Pix entrantes de tu institución a la dirección que sirve el rol `pix-ingress`. El Courier decide el dueño durante la llamada, entrega la llamada al motor y reenvía a JD la respuesta del motor.

JD hace dos tipos de llamada:

* **Preguntas.** JD espera una respuesta antes de continuar: validación de cuenta, el bloqueo del débito de Pix Automático y las validaciones de autorización y de agendamiento. El Courier no retiene una pregunta.
* **Mensajes.** JD informa un hecho: cash-in, devolución y los registros, las liquidaciones y los eventos de Pix Automático. El Courier puede retener un mensaje.

### Qué clave enruta cada llamada

| Llamada de JD | El dueño es el motor dueño de |
| - | - |
| Validación de cuenta, cash-in, devolución | La cuenta del receptor |
| Bloqueo del débito de Pix Automático | La cuenta del bloqueo |
| Débito y reversión del débito de Pix Automático | Ninguna clave: la llamada va al motor que recibió el bloqueo del débito |
| Registro del pagador de la autorización, y su evento | La cuenta del pagador |
| Registro del receptor de la autorización, y su evento | El CNPJ del cobrador |
| Validación, cancelación y eventos de estado de la autorización | La cuenta del pagador, cuando el ISPB del pagador es uno de los tuyos. El CNPJ del cobrador, cuando el ISPB del pagador no es uno de los tuyos. |
| Validación, registro y cancelación del agendamiento, y sus eventos de registro | La recurrencia |
| Evento de estado del agendamiento | La cuenta del receptor |
| Evento de estado de la cancelación del agendamiento | Ninguna clave: la llamada va al motor que tiene el agendamiento |

Tus ISPBs son los ISPBs participantes que el operador registra en los motores.

Las llamadas de Pix Automático que siguen una etapa anterior necesitan un registro de esa etapa. El Courier registra las etapas anteriores que entrega. Para los pagos en curso antes de que el Courier reciba Pix, cada motor declara sus etapas. Consulta [Conectar un motor](/es/interfaces/jd-courier/jd-courier-engine-integration).

### Qué recibe JD

| Situación | Mensaje | Pregunta |
| - | - | - |
| El motor dueño recibe la llamada | La respuesta del motor, tal como llegó. El Courier la guarda y responde con ella a cada reenvío de JD. | La respuesta del motor, tal como llegó. |
| El Courier guarda la llamada, pero no puede enrutarla o entregarla | `503`. El Courier retiene el mensaje. | — |

Cuando el motor responde a un mensaje con un estado `5xx`, `408` o `429`, el Courier reenvía esa respuesta a JD y retiene el mensaje. El siguiente reenvío de JD llega de nuevo al motor. Cuando el motor responde con un estado `3xx`, `401` o `403`, o no responde, JD recibe `503` y el Courier retiene el mensaje.

<h2 id="retained-messages">
  Mensajes retenidos
</h2>

***

Un mensaje retenido queda en la base de datos del Courier con su motivo. El Courier no lo acredita, no lo devuelve a BACEN y no lo elimina. Tu operador lista los mensajes retenidos, del más antiguo al más nuevo, a través de [la API de retenidos](/es/reference/interfaces/jd-courier/list-retained-messages). La lista muestra el motivo y los horarios. No muestra el contenido del mensaje.

| Motivo | Riel | Significado | Verificado de nuevo |
| - | - | - | - |
| `ACCOUNT_UNASSIGNED` | SPB, Pix | El Courier leyó la clave del mensaje, y ningún motor es su dueño. En Pix, también: la etapa anterior del mensaje no tiene registro. | Sí |
| `UNRECOGNIZED_TYPE` | SPB | El mensaje no tiene una clave que el Courier lea, y su código no tiene modo de entrega. | Sí |
| `OWNERSHIP_DECISION_UNAVAILABLE` | Pix | El Courier no pudo leer los datos para la decisión. También se usa cuando un intento anterior envió el mensaje a un motor que ya no es el dueño. | Sí |
| `DELIVERY_FAILED` | SPB, Pix | La entrega al motor falló. | Sí |
| `CLASSIFICATION_FAILED` | SPB, Pix | El Courier no pudo clasificar el mensaje. | No |

### Cómo sale un mensaje retenido

El Courier verifica de nuevo cada mensaje retenido con una causa de enrutamiento o de entrega, como máximo una vez por minuto. Cuando la causa desaparece, el mensaje sale por su cuenta. Por ejemplo, un operador asigna la cuenta, o habilita de nuevo el motor dueño. En Pix, un reenvío de JD también ejecuta la decisión de nuevo.

Un operador también puede [pedir una reevaluación](/es/reference/interfaces/jd-courier/run-a-retained-message-s-routing-decision-again) con un motivo. El Courier registra quién la pidió, cuándo y por qué, y verifica el mensaje primero. La reevaluación ejecuta las mismas reglas de enrutamiento que un mensaje nuevo. El operador nunca elige el motor. El Courier rechaza una reevaluación para el motivo `CLASSIFICATION_FAILED` con `422 JDC-0204`.

Cuando el Courier libera un mensaje Pix, JD no está en la llamada. El Courier guarda la respuesta del motor y se la da a JD en el siguiente reenvío.

<h2 id="sends-to-jd-and-the-send-journal">
  Envíos a JD y el registro de envíos
</h2>

***

Los motores envían sus mensajes SPB a JD a través del rol `spb-sender`. El Courier escribe cada envío en el registro de envíos antes de que el envío salga. Después, envía el mensaje a JD una vez y reenvía al motor la respuesta de JD. El Courier nunca envía un mensaje de nuevo por su cuenta.

El registro de envíos registra uno de estos resultados para cada envío:

| Resultado | Significado |
| - | - |
| `DETERMINED` | JD respondió con un veredicto. |
| `INDETERMINATE` | El mensaje salió, y no volvió ningún veredicto. Posiblemente llegó a JD. |
| `RESOLVED` | Una respuesta posterior de JD resolvió un envío indeterminado. |
| `NOT_SENT` | El mensaje no salió del Courier. |

El Courier acepta cada número de control una vez para cada tenant. Un envío con el resultado `NOT_SENT` no cuenta. Un segundo envío del mismo número de control no llega a JD.

Un envío indeterminado recibe su respuesta cuando el motor consulta a JD sobre él a través del Courier. Para tratar los envíos indeterminados que quedan, consulta [Operación diaria](/es/interfaces/jd-courier/jd-courier-operations).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.