Skip to main content
The Moove API is versioned in the URL path.
Today there is one public version: v1.

​
What can change inside a version

Treat the API as additive within a version. Your client must tolerate new fields appearing.
Backwards-compatible changes ship inside v1 without notice:
  • New endpoints.
  • New optional request fields.
  • New response fields.
  • New values in a non-exhaustive enumeration.
  • Better error messages, under the same code.
Breaking changes do not. A change that removes a field, changes a type, makes an optional field required, or changes the meaning of an existing value would ship as a new path version.

​
Writing a client that survives

Do not use a parser that errors on unrecognised keys. New response fields are additive and will appear.
Error codes are stable. Message text is written for humans and may be reworded at any time.
Payment link status is active, completed or inactive today. Give your client a default branch rather than crashing on a value it has not seen.
limit is returned in every list response. Read it rather than assuming it.
Call /v1/… explicitly. Do not build the path from a value fetched at runtime.

​
The schema is the contract

The machine-readable schema is served live and always matches what production runs: Generate your client from it, and regenerate to pick up additions.

​
Deprecation

When a version is superseded, the current one keeps working while consumers migrate. Deprecations are announced before anything is withdrawn — nothing is removed without notice.
Some fields carry deprecation markers within v1 while a replacement beds in. A deprecated field keeps returning a value; prefer its replacement in new code.

​
Next

Introduction

Base URL and endpoints.

Errors

Stable error codes.

Moove Payment Links

The v1 surface.