Versioning is an essential component of API design. It enables Speed to update new features to old APIs or add new APIs. These updates are almost always backward-compatible; however, there may be a few backward-incompatible changes. If you choose to upgrade with backward-incompatible APIs then to keep your system’s existing functionality intact, you must change the code at your end.

Backward-compatible changes will be additive and rolled out to the most recent version when ready, requiring no developer work unless you want to use the new functionality.

One can then continue to use the old API version or use the new Speed platform API version. A new application is backward compatible when it supports the features of the older versions. We consider the following changes to be backward-compatible:

  • Addition of a new endpoint
  • Addition of a new optional parameter
  • Addition of a new response field
  • Changing text in error messages
  • Adding new enum values.
  • Changing the length or content of any API identifier

A major dated version will be released when a backward-incompatible change is introduced in the API. We will publish migration guides when launching a new major version to assist developers in migrating over to the new version.

Speed Versioning

The following are the main principles of our versioning strategy:

Speed implements rolling versions, which are identified with the date they were released (current version: 2022-04-15). When you create your account, it is automatically pinned to the most recent version available, and any subsequent API calls are implicitly assigned to that version for the developer.

If you are on older version and want to use the latest functionality added to a particular API in another version, you can explicitly pass the speed-header with its new version value while calling the API.

For example:

If you are on older version i.e. 2022-04-15, you can still create a checkout session with speed-header 2022-10-15 and take advantage of the on-chain functionality to receive on-chain payments.

🚫 The system will show an error if a user passes an invalid API version, for example, 2023-04-15, which is not a valid Speed API version.

Speed Versions

As of now, Speed APIs work on two versions: (2022-04-15 and 2022-10-15).


Version: 2022-04-15

This version supports all the lightning network payments.


Version: 2022-10-15

This version supports the lightning network and on-chain payments.

Added support for payment_method,payment_method_options,, payment_method_options.on_chain.address,, payment_method_options.lightning.payment_request, on_chain_tx_explorer_link, target_amount_paid_by, description, and confirmations in Payments.

Removed support for payment_request in Payments.

Added support for payment_method,amount_paid, payments.amount_paid, payments.exchange_rate, payments.target_amount_paid, payments.target_currency in Checkout session.

Change the type of payment_id from string to array of strings in Checkout link.

Added support for payment.payment_method_options.on_chain.payment_request, payment.payment_method_options.lightning.payment_request, exchange_rate, amount_pending, target_amount_pending, expires_at, api_version, payment_methods, amount_paid, payments.amount_paid, payments.exchange_rate, payments.target_amount_paid, payments.target_currencyin Payment page.

Removed support for payment.exchange_rate, payment.target_amount, payment.amount_captured, payment.captured_at, payment.ttl, payment.expires_atpayment.payment_request, payment.statement_descriptor, payment.description in Payment page.

Stay up to date

We send information on Speed’s APIs updates in the Speed Product updates. Be sure to subscribe to stay informed.