Choose who issues the CCB
A product version declares
terms.creditInstrumentMode when you create it. The value is lender_emitted (the default) or client_issued. A version never changes, so a different issuer means a new version.
Lender emits the CCB
1
Publish a document template
The product needs a published template before Lender can emit. Create a draft with
POST /api/v1/loan-products/{productId}/document-templates, then publish it. Publishing a new version replaces the active one. Without an active template, emission answers LENDER-0616.2
Approve the application, then emit before the release
Lender emits only for an
approved application. An application that is already disbursed answers LENDER-0602, so emit between the approval and the release.3
Emit the CCB
POST /api/v1/loan-applications/{applicationId}/credit-instruments takes idempotencyKey in the body, not in a header, and a parties block with the issuer and creditor names and documents, the places of issuance and payment, and any other field the template declares. The same key returns the same CCB, with X-Idempotency-Replayed: true. The same key with a different parties block is refused.4
List and download
GET .../credit-instruments lists the emissions, newest first. An older emission carries supersededByInstrumentId. The issuance block tells you whether the application can have a CCB emitted now (canEmit) and, when it cannot, the code the emission would answer (refusalCode). GET .../credit-instruments/{instrumentId}/download returns the PDF Lender stores.Your institution issues the CCB
On a
client_issued version, Lender emits no CCB. POST .../credit-instruments answers LENDER-0601, and the list shows canEmit: false with the same refusalCode. Render and collect the signature in your own document, then record the signed CCB. Keep the digest of the document as it was before signing: the record is refused with LENDER-0608 when originalDocumentDigest is missing or when creditInstrumentId, which names a CCB Lender emitted, is sent.
Record the signed CCB
Record the signed CCB once the parties have signed, on an application that is
approved or disbursed, in both modes. POST /api/v1/loan-applications/{applicationId}/signed-credit-instrument takes:
This route takes no
X-Idempotency header. Sending the same document again returns the newest record, with X-Idempotency-Replayed: true, and ignores any metadata that differs in the resend: it does not update the record.
Replace the signed CCB
A different document is refused with
LENDER-0604 unless it is a replacement. To replace, read the newest record, then send the new document with supersedes set to that record’s id and a replacementReason of one line, up to 500 characters. Both go together. The replaced record stays in the history, and the newest one counts.
A document that already belongs to an earlier record cannot return as a replacement: Lender answers LENDER-0613. To return to that content, send a new file, such as a new export, whose bytes differ.
Read and download
GET /api/v1/loan-applications/{applicationId}/signed-credit-instrument returns the newest record. custodian says who holds the PDF: lender, or integrator. GET .../signed-credit-instrument/download streams the PDF Lender stores. For a record whose custodian is integrator, it answers LENDER-0614: the PDF stays with the integrator, and the signedDocumentDigest from the read checks its bytes.
Refusals
Each operation’s reference page lists its other refusals: the issue, record, get and download pages, and the template create and publish pages.
In the console
The console shows the CCB of each application under Credit instruments: see Credit instruments.
Next steps
Originate a loan
Walk an application from submission to the release.