Long-Term Support & Stability

Our Stability Promise

When you integrate an API into production, you need confidence that it will keep working. Many API providers treat breaking changes as routine, forcing developers into costly migration cycles. We take the opposite approach: stability is a feature.

Exchange Rate API has been operational since 2005. Integrations built years ago continue to work today without modification. That is not an accident — it is a deliberate engineering and business decision.

API Endpoint Stability

Every endpoint published in our documentation is a commitment. We will not remove, rename, or change the behavior of existing endpoints without an extended deprecation period measured in years, not months.

• No endpoint removals — Once an endpoint is published, it stays. We have never removed an endpoint from our API, and we do not plan to start.
• No behavior changes — The same request will produce the same response structure today as it will next year. Query parameters, response fields, and error formats remain consistent.
• Additive-only evolution — When we add new features, they are added as new optional fields or new endpoints. Existing behavior is never altered.
• Long deprecation periods — In the unlikely event that an endpoint must be retired, we commit to a minimum 24-month deprecation notice with migration guides and direct support.

Versioning Policy

Our API follows a clear versioning policy that protects your integration from unexpected changes.

• v1 supported indefinitely — The current API version (v1) will continue to function for as long as Exchange Rate API operates. There is no planned end-of-life.
• No breaking changes without a major version bump — If we ever introduce changes that are not backward-compatible, they will be released under a new major version (e.g., v2). Your v1 integration will continue working unchanged.
• Parallel version support — If a v2 is ever released, v1 will continue running alongside it with full support. We will never force you to migrate.
• Semantic clarity — Minor improvements (new optional fields, additional currency support, performance enhancements) are released within v1 as non-breaking additions.

No Breaking Changes

We define a "breaking change" broadly to protect you from subtle integration failures. The following will never happen within a major version:

• Removing a response field — If a field exists in the response today, it will continue to exist.
• Changing a field's data type — A number will always be a number. A string will always be a string. No surprises.
• Altering error code semantics — HTTP status codes and error response formats remain consistent so your error handling logic never breaks.
• Changing authentication mechanisms — Your API key will continue to work with the same authentication method it uses today.
• Modifying rate limit behavior — Rate limits for your plan will not become more restrictive. If anything changes, it will be in your favor.

Price Lock Guarantee

Your plan price is locked for life. When you sign up for a plan, that is the price you pay — forever. No surprise increases, no "adjusted pricing," no inflation-based adjustments.

Data Format Consistency

The JSON response format you receive today is the same format you will receive years from now. We treat our response schema as a contract.

• Stable JSON structure — Response objects maintain their shape. Fields are never moved, nested differently, or renamed.
• Consistent precision — Exchange rate decimal precision remains the same. If a rate returns 6 decimal places today, it will return 6 decimal places tomorrow.
• Predictable timestamps — Date and time formats (ISO 8601) are fixed. We will never switch formats or timezones without a new version.
• Additive field policy — New fields may be added to responses over time (e.g., additional metadata), but existing fields will never be removed or changed. Your JSON parser should already handle unknown fields gracefully.
• Consistent encoding — UTF-8 encoding, application/json content type, and gzip compression support are permanent fixtures of our API responses.

SDK Backward Compatibility

Our official SDKs follow the same stability principles as the API itself. Updating to a new SDK version will never break your existing code.

• Semantic versioning — All SDKs follow strict semver. Patch and minor updates are always backward-compatible.
• No forced upgrades — Older SDK versions continue to work against the API indefinitely. You are never required to update.
• Deprecation warnings — Before any SDK method is retired, it is marked as deprecated for at least two major versions, giving you ample time to update at your own pace.
• Long-term runtime support — We maintain SDK compatibility with older language runtimes (Node.js LTS versions, Python 3.8+, etc.) so you do not need to upgrade your entire stack to use our SDK.

Migration Support

In the unlikely event that a change ever requires action on your part, we provide comprehensive migration support to make the transition painless.

• 24-month minimum notice — Any change requiring migration will be announced at least two years in advance via email, documentation banners, and API response headers.
• Detailed migration guides — Step-by-step documentation covering exactly what changed, why, and how to update your integration with code examples in every supported language.
• Parallel operation period — Both the old and new versions run simultaneously during the entire migration window. You choose when to switch.
• Direct engineering support — Our team is available to assist with migrations directly. Enterprise customers receive dedicated migration assistance at no additional cost.
• Automated compatibility checks — We provide tooling to verify your integration against upcoming changes before they go live, so you can confirm everything works before any deadline.