The Native API can be used to access functionality, such as application key management and lifecycle rules.
Using the Backblaze Native API, you can:
- Upload, download, and delete files
- Create and manage the buckets that hold files
- Manage the configuration of your account*
* Backblaze B2 Native APIs only
To get started, you will need to have "B2 Cloud Storage" enabled in your account settings. For detailed instructions, check out the Getting Started guide here.
API Base URL
The base URL that you will use for most of the B2 Native API operations is returned by the b2_authorize_account call. The base URL looks similar to
NNN being the cluster number containing your account. For information about constructing the API URL, see Call the B2 Native API.
Request and Response Formats
The following request and response values are possible using the Native API.
For all calls to Backblaze B2 Cloud Storage, the HTTP status code that is returned indicates success or failure. Unsuccessful calls return a JSON error structure in the body of the response that includes the status: a "code" that is a short string and a "message" that is intended only for humans.
A status of 200 (OK) means success, and 206 (Partial Content) means success when downloading using the Range header. Any code in the 400 or 500 range is a failure. At present, Backblaze B2 does not use redirects (status codes in the 300 range).
Failures to connect to the Backblaze B2 servers and networking problems in general can cause errors, which are reported in a standard format.
If you receive a response from Backblaze B2, the HTTP status code tells you whether it is an error. A status of 200 (OK) means that the call was successful. For most calls, a successful response contains the JSON that is described in the API documentation. Any code other than 200 is an error, and the response contains a JSON error structure indicating what went wrong. The documentation for each API includes information on the specific errors that are returned for that API; the general classes of errors are as follows:
HTTP Status Codes
The general classes of errors are included in the following table:
|The request was successful, and the response contains the JSON structure described in the page for the call.
There is a problem with a passed in request parameters - the JSON error structure returned will contain an error code of
bad_request and a human-readable error message describing the problem.
When uploading data using
For all other API calls, the code returned tells you what to do. The code
You have a reached a storage cap limit, or account access may be impacted in some other way; see the human-readable message.
The service timed out trying to read your request.
|TOO MANY REQUESTS
B2 may limit API requests on a per-account basis.
An unexpected error has occurred.
The service is temporarily unavailable. The human-readable message identifies the nature of the issue, in general we recommend retrying with an exponential backoff between retries in response to this error.
For more detailed information on handling errors, see the Integration Checklist.
JSON Error Structure
|The numeric HTTP status code. Always matches the status in the HTTP response.
|A single-identifier code that identifies the error.
|A human-readable message, in English, indicating what went wrong.
The following example shows a JSON error response:
"status" : 400,
"code" : "invalid_bucket_name",
"message" : "bucket name is too long"
The current version is
Please refer to API Versions for more detailed information about API version history, including breaking changes and compatibility notes.