> 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/guides/versioning.md).

# API versioning

The version is in the URL. Not in an `Accept` header, not in a query parameter, not implied by the auth flow. When you write `/api/v1/…`, you're calling v1 — permanently.

## URL structure

```
https://developers.gallantreecapital.com/api/v1/<resource>[/<id>]
```

* **`v1`** is the current stable version. Everything under `/api/v1/*` is the public developer surface.
* **`<resource>`** is a plural noun.
* **`<id>`** — for detail routes — is the resource's `id` field (a 24-character hex string).

Anything **outside** `/api/v1/*` is internal to the platform and may change at any time without notice. Do not build against `/api/*` routes that aren't inside `/api/v1/*`.

## Version compatibility promise

Within a version (`v1`, `v2`, …):

* **Additive changes are allowed without notice.** New resources, new response fields, new optional request parameters, new webhook event types, new error codes. Design your client to ignore fields it doesn't recognise.
* **Breaking changes require a new version.** Removing a field, changing a type, changing the meaning of a value, tightening a validation rule — any of these force a new URL prefix (`v2`).
* **Deprecations are announced.** Endpoints that will be removed in the next version get a `Deprecation` header pointing at the successor. You'll have at least six months of warning before an endpoint disappears.

## Deprecation header

When a v1 endpoint is being retired in a future version, its response carries:

```
Deprecation: true
Sunset: 2027-01-15T00:00:00Z
Link: <https://developers.gallantreecapital.com/api/v2/loans>; rel="successor-version"
```

Watch for these headers in your integration's logs — the `Sunset` date is when the endpoint is removed, not when the deprecation was announced.

## Pagination

Every list endpoint uses the same query-parameter shape:

| Parameter | Type            | Default          | Notes                                                                             |
| --------- | --------------- | ---------------- | --------------------------------------------------------------------------------- |
| `page`    | integer         | `1`              | 1-indexed                                                                         |
| `limit`   | integer         | `25`             | Max `100`; requesting more returns `400 The limit parameter must be 100 or less.` |
| `sort`    | string          | resource default | Endpoint-specific — see the reference                                             |
| `order`   | `asc` \| `desc` | `desc`           | Only meaningful with `sort`                                                       |

Every list response wraps the array in a `data` field and includes a `pagination` object:

```json
{
  "data": [ ... ],
  "pagination": {
    "page": 2,
    "limit": 25,
    "total": 132,
    "totalPages": 6
  }
}
```

Iterate by incrementing `page` until `page > totalPages`, or track `total` yourself.

## Content negotiation

* **Request:** send `Accept: application/json`. Anything else is ignored.
* **Response:** `Content-Type: application/json; charset=utf-8`. All timestamps are ISO 8601 in UTC.

## Runnable example — walk every page

```bash
page=1
while : ; do
  body=$(curl -sS "https://developers.gallantreecapital.com/api/v1/loans?page=$page&limit=100" \
    -H "x-api-key: $GALLANTREE_API_KEY")
  echo "$body" | jq -r '.data[].id'
  totalPages=$(echo "$body" | jq -r '.pagination.totalPages')
  if [ "$page" -ge "$totalPages" ]; then break; fi
  page=$((page + 1))
done
```


---

# 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/guides/versioning.md?ask=<question>&goal=<endgoal>
```

`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.