API deprecation policy

• New fields on any response object, including inside data[] rows, data_quality and provenance. Parse by key, never by position or count.
• New endpoints and new optional query parameters.
• New values for open string fields such as source, publication_time_basis or returned_reason, and new entries in enumerated selector lists exposed through supported_options.
• New currencies, indicators, commodities and series variants in the data catalogue.
• Key order within JSON objects, whitespace, and the order of equal-ranked items.
• Fields that are omitted when they do not apply. A field documented as optional may be absent on a row and present on the next.
• Longer histories, revised values and corrected timestamps as publishers revise their data (see data corrections).

• Removing or renaming an endpoint, a query parameter, a response field or a selector value.
• Changing the type, unit or meaning of an existing field, or the shape of an existing object.
• Tightening validation so that a request that is valid today would be rejected.
• Changing how a route authenticates or which plans may call it.
• Changing a default, such as the default limit or the default revisions view.

Log the Deprecation header in your client. A single alert on its first appearance gives you the whole notice period to migrate.

• A deprecated endpoint, parameter or field keeps working, with the same data, for at least six months from the date of its changelog entry.
• The removal date is published in the changelog in advance. The route is not removed earlier than that date.
• Deprecations of authentication transports are handled the same way. Where a transport stays accepted indefinitely, its entry below says so.
• Enterprise customers with a signed agreement may have a longer period written into it; this page states the minimum that applies to everyone.

• Publisher revisions change val for a period and add an entry to revisions[]. Use revisions=first or as_of when your work depends on what was known at the time; see point-in-time backtesting.
• Corrections FXMacroData makes to its own timestamps or stored values are recorded on the issue log with their date and scope.
• When a series is re-pointed at a different official source, the change is a changelog entry and the rows the old source wrote are replaced in the same release, so the slug keeps meaning one thing.

Questions about a specific change: info@fxmacrodata.com.