API Changelog and Version Policy
How Lottery Feed API communicates endpoint changes, deprecations, freshness policy changes, and safe client upgrades.
Section
10 / 27
Live API examples
Jump from the docs to real public pages that use the same read models.
Current API version
The customer API is versioned under /v1. The current namespace is stable for the compact public read model: latest results, history, lotteries, countries, states, status, frequency, and result checking.
https://api.lotteryfeedapi.com/v1
What counts as a breaking change
Breaking changes include removing a response field, changing a response field type, changing documented status meanings, tightening required parameters, changing authentication behavior. Non-breaking changes include adding optional response fields, adding enum values with documented fallback behavior, adding new endpoints, adding new filters that keep existing defaults stable.
Deprecation headers
When an endpoint or response field is scheduled for removal, the affected response should include machine-readable deprecation headers and link to this page or the product changelog. No /v2 namespace should be created until there is a real breaking contract need.
Deprecation: true Sunset: Wed, 31 Dec 2026 23:59:59 GMT Link: <https://lotteryfeedapi.com/api-docs/changelog>; rel="deprecation"
Freshness and data-policy changes
Changes to delivery levels, source-confidence labels, result withholding, or fallback-source policy must be documented before customers rely on them. F1-F7 describe plan delivery delay after feed storage, not ingestion or uptime guarantees.
Client upgrade checklist
Generated clients should read the OpenAPI contract, keep unknown enum values safe, ignore unknown optional fields, preserve idempotent GET retry behavior, and run sandbox smoke tests before release. Store changelog checks in CI so docs, generated DTOs, and Postman collections move together.
1. Refresh /openapi.json 2. Regenerate or validate DTOs 3. Run /sdk-examples.json smoke tests with lf_sandbox_* credentials or the documented legacy demo token 4. Check /api-docs/changelog for deprecations 5. Ship only after sandbox requests pass
Where to monitor changes
Use /openapi.json for machine-readable contract drift, /postman-collection.json for manual integration checks, and the public product changelog for release notes. Customer-impacting API changes should link back to the affected docs page.
https://lotteryfeedapi.com/openapi.json https://lotteryfeedapi.com/postman-collection.json https://lotteryfeedapi.com/sdk-examples.json https://lotteryfeedapi.com/api-docs/changelog
API documentation FAQ
Short answers for teams using api changelog and version policy in production integrations.
Will every additive field create a new API version?
No. Optional fields, new endpoints, and enum values with documented fallback behavior are non-breaking in /v1. Clients should ignore unknown optional fields.
When would Lottery Feed API create /v2?
A new namespace should wait for a real breaking contract need, such as changing field types, removing fields, changing auth behavior, or changing documented status meanings.
How should I monitor deprecations automatically?
Watch /openapi.json for contract changes, inspect the x-lottery-feed-version-policy extension, and check Deprecation, Sunset, and Link headers on responses.
Next: Authentication