Skip to main content
A client is a borrower you lend to. Every loan, every payment and every credit decision names a client, so you register the client first and issue the loan second. A registration is never deleted: once an identifier is registered it stays resolvable for as long as its loans and payments need to name it. The Platform does not store who the client is. A registration holds your own identifier for the borrower and an optional label, and nothing else. Names, birth dates and document numbers stay in your systems, so the identifier can be your CRM key or your contract number, and a data request about a person never reaches the Platform because there is nothing about the person here to find.

Register a client

Choose the identifier

Pick a value that is stable for the life of the borrower’s relationship with you: a CRM key, a contract number, anything you can resolve back to a person.

Add a label, if you want one

Free text for your own eyes. The Platform stores it and shows it back, and reads it for nothing.

Send the request

Post it to the clients route. From then on, loans and payments name the borrower by this identifier.
A registration carries these two and nothing else. Any other field is rejected rather than dropped: a request carrying a name answers 400 and says which field it did not expect. Hold everything about the person in your own system, under the same identifier.
Register a client with the clients endpoint, and correct a label with the correction endpoint. The API reference carries the exact format and the error each value returns.

Registering twice

Registration is safe to retry. The Platform compares the repeat with what it recorded and answers one of two ways.
Omitting the label on a retry counts as stating none. If the client was registered with a label, a retry without it is a disagreement and answers 409. Replay the registration as you first sent it.

Correct the label

The label is the one value you can change in place. Send the new label alone, and the identifier and the moment of registration stay as they were.
Correcting to the value already recorded answers 200 and changes nothing. A correction must carry a label: an empty string, null or a body without the field answers 422.
A correction changes what a retry is compared against. After the correction above, re-registering c-0001 with contract-0001 answers 409, and re-registering it with contrato 84-B is the ordinary 200. If your integration replays old registrations, replay the corrected form.

What you can read

Seven reads take the identifier. The last one is all of them at once. A client that belongs to another tenant, or one that was never registered, answers 404 on every one of them. The two answers are the same on purpose. What each of the four before the book means is covered where it belongs: Loans for the loans a client holds, and Payments for receipts, money owed back and what a borrower can pay on a date. A refused registration answers 422 with invalid_identifier or invalid_label, and a disagreeing repeat answers 409 conflicting_registration. Every code is on Errors.

The book: the reading above a loan

Everything else on the Platform answers one Loan at a time. The book answers the Client: every Loan with its standing on the date, and what the Client holds across them. It is one read and one derivation. Use it for an account screen, a collections gate or a morning sweep, in place of a listing plus a read per Loan. It records nothing unless you ask for the payoff. A book is one identifier’s. The Platform never joins two Client identifiers, even when you know they are one person.

FAQ

No. A registration holds your identifier and a label, and a request carrying any other field is rejected by name. Hold the person’s data in your own system under the same id.
No. A registration is never deleted, so an identifier stays resolvable for as long as its loans and payments need to name it. If a client was registered by mistake and nothing names it, it simply stays unused.
Yes. A preview runs every check an issuance runs, and the client is checked first. A preview for an unregistered client answers 422 unknown_client.
No. Identifiers are scoped to your tenancy. Another tenant may register the same id for its own borrower, and neither of you can read or name the other’s record: it answers 404, the same as one that never existed.
Correct it with PATCH …/clients/{client_id} and the new label alone. After that, a retry of the original registration answers 409, because the Platform compares it with what is recorded now. Replay the corrected form.