API Deprecation Policy

How Leadping announces incompatible API changes and retires deprecated API, MCP, webhook, and discovery behavior.

Leadping evolves public integration surfaces without silently removing behavior that active consumers may depend on. This policy covers the public REST API, MCP and A2A surfaces, documented webhooks, SDK-facing contracts, and machine-readable discovery documents.

Compatible changes

Leadping may release backward-compatible changes without a deprecation period. These include adding optional fields, endpoints, response properties, event types, examples, and documentation, and expanding an enum where consumers are expected to tolerate unknown values.

Consumers should ignore unknown response fields and avoid treating an enum as permanently closed unless its schema says otherwise.

Incompatible changes

When a generally available public behavior must change incompatibly, Leadping will:

1. Identify the affected operation, field, event, protocol, or artifact.
2. Mark it deprecated in the relevant machine-readable contract when the format supports deprecation metadata.
3. Publish the replacement path and migration guidance.
4. Record the announcement and planned retirement date in the API changelog.
5. Keep the deprecated behavior available until the published retirement date.

The notice window is set for each change based on consumer impact. The announcement is the authoritative source for its retirement date; Leadping does not currently promise one fixed minimum window for every API surface.

Urgent exceptions

Leadping may shorten or omit a deprecation window when continued behavior creates a security, privacy, legal, compliance, fraud, abuse, or upstream-provider risk. When disclosure is safe and legally permitted, the changelog will explain the exception and the required consumer action.

Finding deprecations

• Review the API changelog.
• Watch for deprecated metadata in the OpenAPI document.
• Follow migration notices in the affected documentation page.
• Contact Leadping support if a retirement affects a production integration.

Use the integration planning guide to assess available capabilities. The changelog and a change-specific deprecation notice describe committed API lifecycle events.

Plan a migration

Keep an inventory of the endpoints, SDK versions, event fields, and discovery documents your integration depends on. When a notice affects one of them, record the retirement date and assign an owner for the replacement.

Test the replacement using the same representative inputs, permissions, and failure cases as the current operation. Compare the resulting records and side effects, not just the response shape. Deploy before the published retirement date and monitor failures on the affected path.

If a deadline creates a production blocker, contact support with the affected operation, current integration version, expected volume, and the obstacle to migration. An extension is not implied by a support request.