Skip to main content
The API version is part of the path: every endpoint lives under /v1. Within a version, Infinity makes only backward-compatible changes, so an integration built against /v1 today keeps working without changes.

Backward-compatible changes

Infinity may make these changes to /v1 at any time, without notice:
  • Adding endpoints.
  • Adding optional request parameters.
  • Adding fields to response objects and events.
  • Adding values to enumerated fields, such as a new payout status, failure_code or rail.
  • Adding event types.
  • Adding error codes.
  • Adding currencies, countries and rails.
  • Changing the wording of error messages.

Breaking changes

These changes are never made within /v1:
  • Removing or renaming an endpoint, parameter, field or enumerated value.
  • Changing a field’s type or meaning.
  • Making an optional parameter required, or tightening validation on an existing parameter.
  • Changing the meaning of an error code.
If a breaking change is ever necessary, it’s released as a new version (/v2), and /v1 continues to operate alongside it.

Building for forward compatibility

  • Ignore unknown fields. Don’t fail when an object or event contains a field you don’t recognise, and avoid strict schema validation on responses.
  • Ignore unknown event types. Acknowledge them with 2xx and discard them.
  • Handle unknown enum values. Treat an unfamiliar status as non-terminal and retrieve the object again later; treat an unfamiliar error code according to its HTTP status and type.
  • Don’t parse error messages. Branch on code.

Changelog

Initial release
The first version of the Infinity API: accounts and wallets, funding addresses and deposits, payees and payee addresses, bank requirements, quotes, payouts and batches, webhook endpoints and events, and the sandbox test helpers.