> For the complete documentation index, see [llms.txt](https://developers.gallantreecapital.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers.gallantreecapital.com/concepts/data-model.md). # Data model Before you start reading and writing loans, spend two minutes on how the resources hang together. The API's shape follows the mental model — if this feels unfamiliar, most integration questions will actually be modelling questions in disguise. ## The core shape Everything an external integrator touches sits under a **lender**. Your API key resolves to exactly one lender, and every response is scoped to what that lender owns. There is no cross-lender surface — the tenant boundary is invisible to you because you can only ever see your side of it. Inside a lender: ``` Lender ├── CapitalProgram(s) ← the fund / mandate / warehouse │ ├── Product(s) ← the loan template a program offers │ └── BaseRate ← the reference rate for pricing │ ├── Loan(s) ← what you're mostly here for │ ├── capitalProgram ← which fund it belongs to │ ├── product ← which template it follows │ ├── borrowingEntity ← the borrower (an Organisation) │ └── collaterals[] ← what secures it │ ├── Organisation(s) ← every non-individual counterparty │ └── (roles: borrower, guarantor, servicer, valuer, broker, …) │ └── Individual(s) ← natural persons └── organisationAssociations[] ← links to Organisations, with a role ``` **Read that top-to-bottom once.** The three levels — CapitalProgram → Product → Loan — are why the API returns `capitalProgramId` and `productId` on every loan: those pointers tell you *which* pool of money funded it and *which* template's rules it follows. ## What each resource is ### CapitalProgram The **fund**, **mandate**, or **warehouse** — whatever your organisation calls the pool of capital that individual loans are drawn from. Every loan belongs to exactly one capital program. Programs carry the domicile, currency, governing law, payment frequency, and total facility size. Read-only via the public API today; managed inside the platform by treasury. Key fields on the DTO: `name`, `category`, `domicile`, `currency`, `totalAmount`, `status`, `stage`, `paymentFrequency`, `baseRateId`. Reference: [`GET /api/v1/capital-programs`](/reference/openapi.md), [`GET /api/v1/capital-programs/{id}`](/reference/openapi.md). ### Product The **loan template** a capital program offers. Bounds the loans that can sit under it — min/max amount, min/max LVR, min/max term, allowed origination types, day-count convention. A capital program can offer multiple products (e.g. a CRE program with senior + mezzanine tranches). Read-only via the public API. Key fields on the DTO: `name`, `type`, `category`, `currency`, `loanMin`/`loanMax`, `minimumLVR`/`maximumLVR`, `minimumTerm`/`maximumTerm`. Reference: [`GET /api/v1/products`](/reference/openapi.md), [`GET /api/v1/products/{id}`](/reference/openapi.md). ### Loan The **star of the show**. A loan is what a borrower actually owes. It references its `capitalProgram`, its `product`, its `borrowingEntity` (an Organisation), and its `collaterals[]`. It carries a `category` (CRE, corporate credit, home loan, etc.), a `status` that walks through the origination-through-repayment lifecycle, and denormalised financial fields (principal, LVR, maturity). Loans support the full read+write cycle. See [Loans](/resources/loans.md). ### Organisation **Every counterparty that isn't a natural person** — borrowers, corporate guarantors, trustees, servicers, brokers, valuers, legal firms, auditors. What role an organisation plays in a specific loan is defined by its `roles[]` list. A single organisation record can carry multiple roles (a company that borrows on one loan and guarantees another). KYB (Know Your Business) status lives on `kybStatus` — a seven-value traffic light: `not_started` / `in_progress` / `verified` / `expiring` / `expired` / `refused` / `blocked`. The source of truth for the underlying verification evidence lives elsewhere; the status field is what's exposed publicly. See [Organisations](/resources/organisations.md). ### Individual **Natural persons** — directors, guarantors, beneficial owners, shareholders. Every individual is associated with at least one organisation (a director *of* something, a guarantor *of* someone) — hence the `organisationAssociations[]` field, which carries both the organisation id and the individual's role within it. KYC (Know Your Customer) status uses the same seven-value traffic light as KYB. See [Individuals](/resources/individuals.md). ### Collateral **What secures a loan.** Most commonly a property (CRE, home loan, etc.), but the shape supports non-property collateral too. Carries valuation, LVR-relevant fields, property type/status, and — for income-producing property — DSCR/ICR/WALE. Reference: [`GET /api/v1/collaterals`](/reference/openapi.md), [`GET /api/v1/collaterals/{id}`](/reference/openapi.md). ### BaseRate **Reference rates for pricing** — SOFR, BBSW, RBA cash rate, etc. Referenced by capital programs and products so that variable-rate loans have a known source of truth for the periodic rate reset. Read-only. Reference: [`GET /api/v1/base-rates`](/reference/openapi.md). ## How the resources compose **Reading a loan tells you almost the whole story.** The DTO gives you the resource ids for the loan's capital program, product, borrowing entity, and collaterals. Follow the pointers when you need the detail: ```bash # 1. Get a loan curl -sS -H "x-api-key: $KEY" \ https://developers.gallantreecapital.com/api/v1/loans/ # 2. Follow to its capital program curl -sS -H "x-api-key: $KEY" \ "https://developers.gallantreecapital.com/api/v1/capital-programs/$CAPITAL_PROGRAM_ID" # 3. Follow to its product curl -sS -H "x-api-key: $KEY" \ "https://developers.gallantreecapital.com/api/v1/products/$PRODUCT_ID" # 4. Follow to its borrower curl -sS -H "x-api-key: $KEY" \ "https://developers.gallantreecapital.com/api/v1/organisations/$BORROWING_ENTITY_ID" ``` There is no `?expand=...` parameter that inlines related resources — each is its own fetch. That keeps the response shape stable and gives you control over what you actually need. If your integration is polling for changes, subscribe to [webhooks](/webhooks/subscribe.md) instead of walking the graph repeatedly. ## What "lender-scoped" means in practice * Your key **cannot** see another lender's data. `GET /api/v1/loans` returns only your loans; you cannot query, filter, or discover other lenders' data through the API. * The 404 responses on missing resources are deliberately indistinguishable from "you don't have access to this resource" — the API does not confirm the existence of records outside your tenant. * Writes cascade the tenant scope: a loan you create is automatically tagged to your lender; you cannot create resources for another lender. If your organisation manages multiple lenders (a multi-tenant integration), register a separate app per lender. Each app gets its own scoped API keys. ## Where to go next * Ready to create a loan? [**Loans**](/resources/loans.md) — the create flow is a superset of the ADR006 handover shape, so you can build the whole thing in one request. * Adding borrowers? [**Organisations**](/resources/organisations.md) and [**Individuals**](/resources/individuals.md). * Need the full field list? The [**API reference**](/reference/openapi.md) enumerates every field on every DTO. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://developers.gallantreecapital.com/concepts/data-model.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.