Compatibility policy for LedgerLine developer infrastructure.

Backward-Compatible

Changes clients should tolerate.

• Adding optional response fields.
• Adding new endpoints or route examples.
• Adding new event types while receivers tolerate unknown types.
• Adding new enum values where clients are expected to ignore unknown values.
• Adding optional request fields.
• Adding SDK helpers or OpenAPI examples.

Breaking

Changes that need explicit notice.

• Removing or renaming fields.
• Changing required request fields.
• Changing auth, scoping, idempotency, or error-code semantics.
• Changing accounting side effects, posting, reversal, or report calculations.
• Removing endpoints or changing webhook payloads incompatibly.
• Turning on broad enforcement behavior that blocks existing integrations.

Deprecation Policy

Deprecate before removing.

Deprecated behavior should be marked in docs first, include a replacement path, be reflected in OpenAPI and SDK docs, and keep behavior stable during a notice window where feasible. While LedgerLine is pre-production, these windows are guidance rather than a contractual SLA.

OpenAPI, SDK, Webhooks

Compatibility spans more than HTTP routes.

OpenAPI changes should pass npm run validate:openapiand be recorded in the changelog. Future published SDK packages should use semantic versioning. Webhook receivers should be idempotent and tolerate new event types or optional fields.