> ## 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. # Connecting an engine > What the team of each core banking engine changes and implements to work behind JD Courier, on the SPB rail and the Pix rail. This page is for the team of each engine that works behind the Courier: your existing core and the Lerian stack. An operator first registers the engine in the Courier, through the [engine API](/en/reference/interfaces/jd-courier/register-an-engine). The registration holds the participant ISPBs of the engine and, for Pix, the address where the engine receives Pix calls. ## SPB: point the engine at the Courier *** On the SPB rail, the Courier serves the same SOAP interface as JD. An engine that already talks to JD changes the address and the channel credential. It keeps its messages and its calls. The `spb-sender` role serves the interface at the path `/soap`, on its own port (default `8081`). It accepts the four JD operations: | Operation | What the Courier does | | - | - | | `RecebeMensagem` | Gives the engine the oldest SPB message that waits for it. When none waits, it answers with the empty-queue code `ALS01`. The Courier does not call JD. | | `EnviaMensagem` | Writes the send in the send journal, sends the message to JD once, and relays the answer of JD. | | `ConsultaNumCtrlIF` | Forwards the query to JD, for the control numbers of the sends that this engine made through the Courier. | | `ConsultaMensagem` | Forwards the query to JD, for the sequence numbers of the messages of this engine. | Each engine signs in to the Courier's SOAP address with its own channel credential, not with your JD credential. An operator issues the credential through the Courier API. The response shows the password once. Store it then. When you issue a new credential for the same engine, the previous one keeps working for an overlap window (24 hours by default), then stops. An operator can revoke a credential at any time. The Courier forwards each send to JD with your JD credential. A refused sign-in gets 401 with no body. ### Before the engine changes its address 1. Clear the reconciliation backlog of the engine against JD. The Courier answers a query only for the sends and messages that passed through it. A query about an earlier send receives `503`. 2. Ask the operator to issue the channel credential of the engine. 3. Change the JD address and credential of the engine to the values of the Courier. ### What the engine receives A redelivered message keeps its original sequence number (`NumCabSeq`). The engine must accept a repeated sequence number as a repeat, not as a new message. The Courier gives these answers to `EnviaMensagem`: | Answer | Meaning | | - | - | | The answer of JD, as it came | JD answered. | | The answer of JD with the header `X-Send-Outcome: indeterminate` | JD failed or answered without a verdict. The message possibly reached JD. | | `503` with `X-Send-Outcome: indeterminate` and `X-Control-Id` | The message left and no answer came back. It possibly reached JD. | | `503` with `X-Send-Outcome: duplicate` | The control number already has a send. The Courier did not send the message. | | `503` without `X-Send-Outcome` | The message did not reach JD. | After an indeterminate send, query the control number with `ConsultaNumCtrlIF`. A final answer of JD settles the send in the journal. Do not send the message again with the same control number: the Courier refuses it. When every earlier send of the control number has the outcome `NOT_SENT`, the Courier answers the query with the JD code `ALN01`, and it does not forward the query. ## Pix: receive the calls of JD *** On the Pix rail, the Courier delivers each inbound call to the Pix address of the owner engine. The engine serves the same paths that JD calls, for the account validation, the cash-in, the refund, and the Pix Automático calls. ### How the Courier calls the engine * The Courier appends the path of the JD call to the Pix address of the engine. It uses the same method. * The body is the body that JD sent, byte for byte. * The Courier forwards these headers when JD sends them: `Chave-Idempotencia`, `X-DataHoraEvento`, `X-NomeEvento`, and `Content-Type`. * The Courier waits up to 60 seconds for the answer. It reads up to 1 MiB of the answer. * The Courier does not follow redirects. To deliver Pix messages, the Courier calls the Pix address you register for each engine. Register a credential for every engine: the Courier then sends an Access Manager token with each call. Without a credential, the Courier calls the engine without authentication. In production, use an https address. Registering a Pix address requires the `pix-delivery:write` permission. The engine's client ID and secret live in AWS Secrets Manager. See [Deployment](/en/interfaces/jd-courier/jd-courier-deployment#pix). ### How the Courier reads the answer The Courier relays the answer of the engine to JD. For a message, the status decides what happens next: | Status of the engine | Result | | - | - | | `5xx`, `408`, `429` | The Courier relays the answer to JD and retains the message. The next resend of JD reaches the engine again. | | `3xx`, `401`, `403`, or no answer | JD receives `503`, and the Courier retains the message. | | Any other status, for example `200`, `400`, or `422` | The message is delivered. The Courier stores the answer and gives it to JD at each resend. | A status from the last row is final. To have JD send the message again, answer with a status from the first row. The engine can receive the same message more than once. For example, the Courier calls the engine again after a timeout. Use the identifiers that JD sends, such as `Chave-Idempotencia`, to recognize a repeat. ## Calls the engine makes to the Courier *** The `admin` role serves three operations for the engines. Each engine calls the ownership API with its own Access Manager application. The application needs the `ownership:read` permission, and `ownership:write` to claim its own Pix Automático recurrences and declare their payment legs. The Courier answers 401 to any other caller. ### Ownership lookup Before the engine settles a payment inside your institution, it must know which engine owns the destination. Call the [ownership lookup](/en/reference/interfaces/jd-courier/resolve-which-engine-owns-a-key) with the key as you hold it. The answer tells if the key has an owner, and if that owner is the engine that made the call. The answer is authoritative: * `200` with `resolved: true` names the owner. * `200` with `resolved: false` means that no engine of your institution owns the key. * `422` means that the key is not valid. * Treat any other status as a refusal: fail the payment and do not settle it inside your institution. ### Pix Automático recurrence claim When the engine authorizes a Pix Automático recurrence, it [claims the recurrence](/en/reference/interfaces/jd-courier/claim-a-pix-automatico-recurrence-for-the-calling-engine). The Courier then routes the schedule calls of that recurrence to the engine. The claim is idempotent. A recurrence that another engine holds receives `409 JDC-0102`. Only an operator can move it. Before the Courier starts to receive Pix, each engine claims the recurrences that already exist. A schedule message for a recurrence without an owner stays retained until the claim arrives. A schedule validation for that recurrence receives `503`. ### Pix Automático leg declaration Some Pix Automático calls follow an earlier leg of the same payment. A debit and a debit reversal go to the engine that received the debit block. A schedule cancellation status goes to the engine that holds the schedule. Before the Courier starts to receive Pix, each engine [declares the legs it holds](/en/reference/interfaces/jd-courier/declare-an-earlier-leg-of-a-pix-automatico-payment-the-calling-engine-holds) for the payments in progress: * `block`: each debit block that the engine accepted, when the debit or its reversal has not arrived yet. * `schedule`: each schedule whose cancellation status has not arrived yet. A call that arrives before its leg is declared stays retained. The Courier releases it after the declaration. A declaration that conflicts with the record of the Courier receives `409 JDC-0116`. Stop and report it to an operator. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.