Versioning

The API lives under /v1, and changes inside /v1 are additive only. We may add:

• new operations and new optional parameters;
• new fields in responses and webhook payloads;
• new values in enumerations (a new Lead status, a new event type);
• new optional fields in requests.

We won't remove or rename an operation, a field or a value, narrow a type, or make an optional input required. A CI check compares every change with the published contract and fails on any of those.

Write clients that tolerate additions: ignore fields you don't know, handle unknown enum values and event types gracefully, and don't depend on the order of JSON keys.

Deprecation

If something must go, it is first marked deprecated and keeps working. Every answer from it then carries:

Deprecation: @1798761600
Sunset: Thu, 01 Jul 2027 00:00:00 GMT
Link: <https://www.letsrealty.io/en/developers/versioning>; rel="deprecation"

• Deprecation (RFC 9745) — since when, as a Unix timestamp.
• Sunset (RFC 8594) — when it stops working.
• Link — where to read about the replacement.

The operation is also flagged deprecated in the API reference. Log these headers in your client so you hear about a sunset early.

Webhook payloads

Event envelopes carry "version": 1. Payloads grow like the API does — new fields only. A breaking change to a payload would ship as a new version.

The contract

The published OpenAPI 3.1 document, with every public operation and webhook payload, is at /openapi.json. Generate a client from it, or diff it against the copy you built with.