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 covers the authenticated endpoints: Generate your client from it, and regenerate to pick up additions.
The public GET /v1/payment-link/{id} is served in production but is not in the schema. A generated client will not include it — add it by hand from Moove Payment Links.

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

​
Next

Introduction

Base URL and endpoints.

Errors

Stable error codes.

Moove Payment Links

The v1 surface.