> ## Documentation Index > Fetch the complete documentation index at: https://docs.capcells.com/llms.txt > Use this file to discover all available pages before exploring further. # Credit sources > How the Platform reaches a source of credit information under your own standing with it, what it records, and how custody of what comes back ends. A **Source** is somewhere the Platform reads credit information about a person you are deciding about, a credit bureau, an alternative bureau, an open-banking provider, or the Platform's own loan book. The Platform reaches every one of them **as your instrument, under your own standing**, and never on its own account. That sentence is the whole design and everything below follows from it. | Thing | Whose it is | | - | - | | The contract with the bureau | Yours | | The credentials | Yours. The Platform holds them sealed and queries with them | | The borrower's authorisation | Yours. You capture it and you hold the document | | The attestation that you hold it | Yours. The Platform forwards it and composes none of its own | | The record of every lookup | Yours to show a regulator. The Platform keeps it and serves it to you | The Platform never fills a signed-authorisation field on your behalf. A dispatch without your explicit attestation is refused, whatever else was supplied. ## The catalogue The set of sources is closed and declared in the Platform's own code. A source that is not declared cannot be reached, and a declaration states five things before the Platform will start with it. | Part | What it says | | - | - | | Failure posture | What a failure to reach it means for a decision that needed it. Four, below | | Prohibition | Whether reading it discharges a legal duty. Such a source may declare neither proceed nor retry | | Transport | Over the network, or in process | | Requirements | Which identifying fields address a lookup, whether it needs your credentials, and whether it needs the borrower's authorisation | | Cost unit | What one lookup spends, in the source's own word | The four postures, and what each records: | Posture | What a failure does | What the decision says afterwards | | - | - | - | | `retry` | Answers the failure as transport. **No Decision is recorded** and the reference stays free, so the same application is resubmitted under the same reference and authorisation once the source recovers | Nothing, there is no decision | | `proceed_and_record` | Decides without the source, its attributes in their absent state | The outcome the policy reached, with the source's entry marked unavailable under `proceed_and_record` | | `refuse` | Settles the outcome as refuse, after the policy has run | `refuse`, carrying no band, no rate and no moratorium, the outcome is not a band's. The trace still says what the policy made of the reading it had, and the source's entry names the posture that overrode it. It bars nobody: a source that could not be reached says nothing about the applicant | | `refer` | Settles the outcome as refer | `refer`, on the same terms. Final the way every referral is: resubmitting the reference answers the decision that stands | Two sources failing under opposite postures settle to `refuse`. It is not a tie broken by ordering. It is the stricter of two standing instructions. The posture is recorded on the decision, not looked up when one is read, so changing a source's posture never changes what a past decision replays to. The Platform's own loan book is a source. It is reached in process, needs no credentials and no authorisation: nobody authorises the Platform to read what it recorded itself, and answers what your repayment history with a client actually is rather than what somebody declared it to be. A network source declares two more things the catalogue read serves you: which identity fields admit an alternative (`identity_any_of`, meaning "RFC or CURP"), and its **failure vocabulary**, the closed set of outcome names its attempts record, each marked retryable or not, so your handling is written against the declared set rather than reverse-engineered from an outage. The first network source: the credential document, the identity fields, the consulta, the folio, and what its failure means. ## Enabling a source Nothing is enabled by default. Enabling is a recorded act performed by a named person at the Console, and it states how many lookups a day that source may make on your behalf. ### Enable it `PUT /v1/tenants/{tenant_id}/sources/{source}/enablement`, at the Console, stating `daily_bound`. The bound is required: a lookup spends your money, and the Platform will not choose the number for you. ### Credentials `POST /v1/tenants/{tenant_id}/sources/{source}/credentials`, at the Console. The Platform seals them and never shows them again, not to you, not in a log, not in an error. ### Read the state `GET` the same path to see which credentials are live, which you withdrew, and which are within thirty days of the expiry you stated. Withdrawing a credential binds at once: the next lookup is refused. Work already in flight completes, because a lookup that has left is one your account is billed for whatever happens next. Rotating is the other order. Supply the new credential first, then withdraw the old one, because supplying does not withdraw what is there, so there is no window in which you cannot look anything up. ## Lookups A dispatch to a source that reads a borrower's file carries four things about authorisation, and the Platform checks all four **before anything is fetched**. | Field | What it is | | - | - | | `consent_artifact_id` | Your own record of the authorisation | | Given at | When the borrower gave it | | Validity window | How long it runs, as your document and its law state | | Attestation | Your explicit statement that you hold what that source's law requires | A missing, expired or unattested authorisation refuses the dispatch naming which, and no call leaves. That timing is the point: at a Mexican bureau, a lookup registers an enquiry on the borrower's file for twenty-four months, so checking afterwards would mean the enquiry had already happened before the Platform noticed nobody was authorised. ## Refusals Everything the Platform can answer from what it already holds is answered before a call leaves. | Status | Code | When | | - | - | - | | `404` | `unknown_source` | The source is not one the Platform declares | | `422` | `source_not_enabled` | You have not enabled it, or you withdrew it | | `422` | `no_credential` | You have supplied none | | `422` | `credential_revoked` | Every credential you supplied has been withdrawn | | `422` | `no_consent` | The application names no authorisation, or states no moment or window for one | | `422` | `consent_expired` | Its validity window has passed | | `422` | `unattested` | You attest nothing | | `422` | `missing_identity` | The lookup cannot address the person the source requires it to name | | `429` | `source_quota_spent` | The dispatch would exceed the daily bound you stated. The answer says when the next one is admitted | These are the source surface's own codes. On `POST /credit-decisions`, the one route that dispatches. Most of the platform-side refusals above arrive as `422` under the single code `source_access`, carrying the same sentence inside it, so one branch of your integration handles all of them. Two do not, because the remedy is not the same one. | Refusal | On the decide route | Why it stands apart | | - | - | - | | Your daily bound is spent | `429` `source_quota_spent`, with `Retry-After` | Nothing about the application is wrong. Wait, or raise the bound, a retry with a corrected body meets the same answer | | The source was reached and did not answer | `424` `source_unavailable`, naming the attempt | Under the `retry` posture. No decision is recorded and the reference stays free | ## The ledger `GET /v1/tenants/{tenant_id}/source-ledger` answers every lookup made on your behalf: when, which source, about which client, under which application, under which authorisation, what came of it, the source's own reference where it assigned one, and what it cost. It carries no payloads. Not the request, not the response, not the report. It is evidence that a lookup happened and under what authority, which is the duty it serves, and never a second copy of a person's credit file. Narrow it to one client with `client_id`, which is the shape the question actually arrives in: a person asks their lender what was looked up about them. ## Custody Two things come back from a lookup that the Platform holds: the identifying fields it was addressed by, and the source's raw response. Both live **beside** the decision they served, never inside it. That split is what makes two promises true at once. A decision is never edited and never deleted. It is what the Platform can be asked to reproduce years later. What was held about the person can be destroyed whole, and destroying it leaves the decision reading exactly as it did: every derived attribute, the trace, the outcome, the source's own reference. **The Platform's position, in full:** * Identity and reports are held while you remain a client. * At offboarding you elect **return** or **destruction**. A return hands you the files whole and then the Platform stops holding them: a return that left a copy here would be custody that did not end. * Absent an election within **90 days**, the Platform destroys. * Every destroyed file leaves one ledger entry naming the client whose file it was and the day it went, so "was mine among them" is answerable without a join nobody kept. * The decision records and the ledger entries recording each lookup are untouched by any of this. Requests from the data subjects themselves, a borrower asking what is held about them, or asking for it to be corrected or removed, route to you, not to the Platform. You hold the relationship, you captured the authorisation, and you are who they contracted with. The Platform answers you. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.