Versioning

.md

What we can change without warning, and what we cannot.

The version is the first path segment, right after the host:

https://api.proppertrading.com/v1/affiliates/pre-registrations
                              ^^

What can change inside v1

We treat these as additive and may ship them at any time, so your integration has to tolerate them:

  • New fields in a response.
  • New optional request parameters.
  • New endpoints.
  • New values in an enum-like field, including new error.code values.
  • New scopes.

Parse responses so unknown fields are ignored, and handle an unrecognised error.code by falling back on error.type.

What will not change inside v1

  • Removing or renaming a field.
  • Changing the type or meaning of a field.
  • Removing an endpoint.
  • Changing what an existing error.code means.

Anything in that list goes to /v2.

One exception so far

On 2026-10-08 the ids under /v1/me changed from numbers to strings without a new version, in the calendar and in the mail alike. Those endpoints act as a person and only our own apps were calling them, so moving them to /v2 would have kept two versions alive for nobody. The changelog lists every field involved.

Deprecation

When we do retire something, the responses involved carry Deprecation and Sunset headers, it is announced in the changelog, and you get at least six months.