Introduction - Nest Veterinary

Welcome to the NestVet API, v3. With this API you can programmatically access clinics, products, invoices, invoice lines, consumption logs, pet benefits, charges, charge payments, charge adjustments, charge refunds, payment plans, payment intents, cancellation payment intents, pets, and subscriptions for your organization — plus live read-only access to your Stripe data via the psp-* endpoints.

Base URL

All endpoints are available under the following base URL:

https://practice-data.nest.vet/api/v3

Authentication

Send a single Authorization: Bearer <api key> header on every request. The key resolves to your organization, and every request is scoped to it automatically.

Authorization: Bearer <YOUR_API_KEY>
Content-Type: application/json

An organization field in the request body is optional. If included, it must match the organization your key resolves to, or the request is rejected with 400.

Request mechanism

Every endpoint — including list endpoints — takes a POST with a JSON body, matching the request mechanism of the earlier API.

Pagination

List endpoints accept a JSON body with these common fields:

{
  "limit": 100,
  "offset": 0,
  "cursor": null
}

limit: Max number of items to return (default 100)
offset: Number of items to skip. Still supported, but deprecated in favor of cursor — see below.
cursor: Opaque resume token from a previous response’s next_cursor. Use it instead of offset to page through large result sets. cursor and a non-default offset cannot both be set on the same request; doing so returns a 400.

Every list response includes a next_cursor field alongside body:

{
  "body": [ ... ],
  "next_cursor": "eyJ..."
}

next_cursor is null once you’ve reached the last page. To fetch the next page, pass it back as cursor on your next request:

{
  "limit": 100,
  "cursor": "eyJ..."
}

Cursors are opaque — don’t parse or construct one yourself, since the encoding may change.

Why prefer `cursor` over `offset`?

A large offset forces the API to compute and discard every skipped row before it can return your page, so requests get progressively slower the deeper you page — noticeable once you’re paging through more than a few thousand records. cursor resumes directly from your last position instead and stays fast at any depth.

Ordering

Results are ordered ascending by last-modified time, with id breaking ties so paging stays stable across rows that share a timestamp. A record that hasn’t been modified since it was created sorts before ones that have.

Consistency

Pagination reflects live data, not a fixed snapshot. If a record is modified while you’re still working through the pages of a search, you may see it again on a later page (with cursor) or, less commonly, miss it entirely (with offset). This is standard behavior for APIs that paginate over continuously-changing data, and it’s the same tradeoff you’d see from most delta-sync APIs. If your integration needs to process each record exactly once, de-duplicate by id as you consume pages rather than assuming each id appears only once across a full traversal.

Feel free to reach out to our support team if you have any questions or need help getting started!

​Base URL

​Authentication

​Request mechanism

​Pagination

​Why prefer cursor over offset?

​Ordering

​Consistency