> 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/getting-started/environments.md). # Environments The Developer API is available in two environments. They are fully isolated — separate databases, separate credentials, and different data lifecycles. | Environment | Base URL | Purpose | Data | | -------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | **Sandbox** | `https://developers.gallantreecapital.com` | Integration testing, sample dashboards, CI runs against a stable seed dataset | Synthetic (obviously-fake lender + loan names, safe to leak in screenshots or bug reports) | | **Production** | `https://developers.gallantreecapital.com` (once your lender is provisioned) | Real integrations against real data | Real lender data — every request is audited | ## One host, two environments Both environments share the developer host `developers.gallantreecapital.com`. What separates them is your **API key**: sandbox keys route to the sandbox database, production keys route to the production database. You cannot cross the boundary — a sandbox key on a production route returns `401`, and vice versa. This is deliberate: it means the URLs you copy from these docs work in both environments without change. The only thing you swap when you go live is the key. ## How to tell them apart * **In the portal.** Every app and every key has a coloured environment pill. Sandbox is yellow; production is red. Look at the pill before you copy a key into a config vault. * **In your app's environment field.** The `environment` property on the app resource is `sandbox` or `production`. Query it programmatically if you need to guard-rail an environment mismatch at boot time. * **All keys share the `gt_` prefix.** The prefix does not encode the environment — that's a property of the app the key belongs to. Use the portal pill or the app's `environment` field to be sure. ## Data lifecycle * **Sandbox** is re-seeded on demand — the dataset is designed to demonstrate every response shape you'll see in production, but the specific records may change between releases. Do not build regression tests that pin on specific sandbox IDs. * **Production** is durable. Records never disappear silently; deletions are audited and often soft. ## Webhooks Webhook subscriptions are scoped to an app, so a sandbox subscription only ever fires from sandbox events, and vice versa. This lets you develop against a sandbox receiver without any risk of picking up a production payload. See [Subscribe to events](/webhooks/subscribe.md). ## Going live When your integration is ready for production: 1. Register a **production** app in the portal (against your real lender). 2. Generate a production API key; store it separately from your sandbox key. 3. Update your app's config so the base URL stays the same but the key swaps. 4. Re-run your smoke tests against production before wiring it into live traffic. Because both environments live at the same host, there is no infra change on your side. It's a credential swap. ## What's in the sandbox The sandbox is seeded with a small, deterministic dataset so your integration has something realistic to talk to from day one. Every record uses obviously-synthetic names — screenshots are safe to share. * **Two demo developer apps** — one read-only (all Tier 1 read scopes), one full-access (writes + webhooks). Create your own app for real integration work; the demo apps are there so a fresh visitor can watch a response come back before they register. * **Two demo lenders** — `Sandbox Lender Alpha` and `Sandbox Lender Beta`. * **A handful of loans** across a couple of capital programs. * **A few borrower organisations and individuals** — the names all start with `Test …` or `Sandbox …`. * **Two webhook subscriptions** pointing at placeholder receivers so you can watch events flow. The sandbox re-seeds on demand and may change between releases — do **not** hard-code any sandbox record's `id` in a regression test. Query by the fields you actually care about (reference number, status, etc.) and expect the underlying records to move. ## How the sandbox host reaches the sandbox app You don't need to know this to use the sandbox — but if you're curious: `developers.gallantreecapital.com` is a Cloudflare-routed host. Requests to `/`, `/getting-started/*`, `/guides/*` etc. serve from the GitBook space (the docs you're reading). Requests to `/api/v1/*`, `/api/auth/oauth/*`, and `/api/health` are forwarded to a dedicated sandbox deployment. Everything else falls through to GitBook, which returns a static 404 — so an unenumerated path can never accidentally reach the API. The rules that decide this live in the platform repository under `deploy/cloudflare/developers/` — reviewable, versioned, and applied to Cloudflare by an operator on merge. --- # 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/getting-started/environments.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.