Source Code Bundles
Over time, the Backblaze B2 APIs get updated to support new features, and to make them easier to use. When changes are not compatible, we make a new version of the API, and keep supporting the old versions.
Specifying an API Version
When you call an API, you include the API version number in the URL
of the call. The path for an API call starts with something like
The current version number is
In general, you should always used the latest version number. And you should update your client code periodically to take advantage of the latest version. The latest version will have the latest performance improvements, and may be the only place to get the latest features. In general, our goal is that upgrading from one version to the next will be straightforward.
Support for Old Versions
Backblaze does not have any plans to stop supporting old versions. If we ever do make such plans, we will announce them at least a year in advance, to give you plenty of time to update your code.
Over time, the B2 APIs will grow to support new features. As they grow, the APIs will change.
The URLs for the APIs include a version number ("v2") in the path. This remains the same as long as the API stays compatible. When we have to make an incompatible change, the new version of the API gets a new version number ("v2"), and the old API will continue to be supported for a while.
When a new version of the APIs is created, usually only a few of the calls
actually change. The new version number is used to get the new version
of those calls, and can also be used for all of the other calls.
For example, if
Some API changes are compatible, and don't require a version change. These can happen at any time, and your code should be able to deal with them:
These are incompatible changes, and won't happen without going to a new API version number:
The current version is
The list of versions below describes the changes in each version.
v2: Remove application key workaround (Sept 13, 2018)
See Application Keys for information on how to work with application keys that have bucket and file name restrictions.
To make it easier to work with application keys with restricted access:
To simplify B2 clients, all API calls that return information about files now return the same structure. This means that some calls return more fields:
And because making a new API version is a good time to drop deprecated fields, these fields are not present when you use v2:
v1: Workaround for existing applications and application keys (August 9, 2018)
Because some existing integrations were having trouble with
the incompatibility in the July 26 release,
we broke our own rules and changed the behavior of
some calls to help existing software support the new
Application Keys feature.
The updated v1 as of this release implicitly restricts
v1: Application keys (July 26, 2018)
This release was incompatible with previous releases because it broke an (unwritten) rule that once you authenticate, all of the calls will be authorized. If you authenticate with an application key that has restricted capabilities, is restricted to a bucket, or is restricted to a file name prefix, some calls will return a 401 Unauthorized.
We didn't anticipate the quick uptake of users making these keys and using them in existing integrations which, very reasonably, weren't prepared for the restrictions, which is the reason for the workaround released on August 9.
v1: Original release (September 22, 2015)
Version 1 of the APIs launched when the B2 Storage service launched.