Backblaze B2 Cloud Storage S3 Compatible API

Number of APIs: 17

The Backblaze B2 Cloud Storage S3 Compatible API implements the most commonly used actions from the AWS S3 API, and easily integrates with your existing applications, data management tools, and S3 gateways. Backblaze B2 Cloud Storage is ¼ the price of AWS S3 so you can quickly integrate B2 and see dramatic savings on your cloud storage bill.

If you aren’t already a Backblaze B2 user you can signup for an account today and get your first 10GB of storage free.

Most applications and scripts use one of the AWS SDKs or the S3 commands in the AWS CLI to access B2. All of the SDKs, and the CLI, allow you to override the default Amazon S3 endpoint in favor of Backblaze B2. Sometimes, though, you might want to interact directly with B2 via the S3 Compatibility API, perhaps in debugging an issue, or just to better understand how the service works. This documentation is the definitive reference for accessing Backblaze B2 directly via the S3 Compatibility API.

Prerequisites

Signup for a Backblaze account, if you have not already done so.
Ensure that B2 is enabled on your account.
Create an application key, if you have not already done so. Ensure that you save the application key now as you will not be able to access it later. Note that you cannot use your master application key with the S3 Compatible API.
Create a bucket, if you have not already done so. Note the bucket's Endpoint URL. It will have the form s3..backblazeb2.com, where is similar to us-west-004. Make a note of the region. Note that at present, unlike Amazon S3, a B2 account is associated with a single region. It is not currently possible to create buckets outside an account's region.

Once you have your application key and region, navigate to the API's collection variables (Click on Backblaze B2 Cloud Storage S3 Compatible API in the tree on the left then click the Variables tab). Copy your application key, application key id and region into the current values of the three variables:

Test your settings

Go to [S3 Get Bucket Location]
Enter the name of a bucket to which your application key has access.
Click Send.

You should see an XML response with the location of the bucket:

Troubleshooting

If you don't see an XML response with the bucket location, check that:

The application key has access to the bucket that you specified.
You didn't inadvertently swap the application key and application key ID.
You saved the collection variables.

Authentication

The API supports AWS Signature Version 4 (SigV4) for authentication and does not support V2 signatures at this time. This collection uses Qodex's built-in implementation of AWS SigV4.

Requests

Communicate with the API by sending HTTP requests to resource endpoints. The HTTP method determines the action taken.

Method	Usage
DELETE	Use the DELETE method to destroy a resource such as a bucket, object or bucket setting. If it is not found, the operation will return a 4xx error and an appropriate message.
GET	To retrieve object data or configuration, use the GET method. Object data is returned in the format it was written; configuration is returned as XML. GET methods are read-only and do not modify any resources.
PUT	Use the PUT method to write object data or configuration. Configuration must be formatted as XML according to the schema defined by the Amazon S3 API.
POST	Use the POST method with the S3 Delete Object, S3 Complete Multipart Upload, and S3 Create Multipart Upload operations.

Response Codes

The API uses standard HTTP response codes to show the outcome of requests. Response codes in the 2xx range indicate success, while codes in the 4xx range indicate a client-side error, such as an authorization failure or a malformed request. 4xx errors return an XML response object explaining the problem. For example:


<Error>
    <Code>NoSuchBucket</Code>
    <Message>The specified bucket does not exist: NonExistentBucket</Message>
    <Resource>NonExistentBucket</Resource>
</Error>

Codes in the 5xx range indicate a server-side problem preventing B2 from fulfilling your request, and include JSON diagnostics:

{
    "code": "internal_error",
    "message": "incident id 2f0e432cc922-9c2c28e96a16711b",
    "status": 500
}

Response	Description
200 OK	The response contains your requested information.
201 Created	Your request was accepted. The resource was created.
202 Accepted	Your request was accepted. The resource was created or updated.
204 No Content	Your request succeeded, there is no additional information returned.
400 Bad Request	Your request was malformed.
401 Unauthorized	You did not supply valid authentication credentials.
403 Forbidden	You are not allowed to perform that action.
404 Not Found	No results were found for your request.
429 Too Many Requests	Your request exceeded the API rate limit.
500 Internal Server Error	We were unable to perform the request due to server-side problems.

Differences from Amazon S3

For the most part, the Backblaze B2 Cloud Storage S3 Compatible API operates identically to Amazon S3. There are, however, some important differences that you should bear in mind with designing applications and solutions.

Backblaze B2 endpoints are located at backblazeb2.com rather than amazonaws.com. Most S3-compatible applications and tools allow you to customize the S3 endpoint to work with S3-compatible APIs outside Amazon.
ACLs are set at the bucket level, and only the canned ACL values private and “public-read” are supported. You cannot set complex ACLs via XML. Objects inherit their bucket's ACL. Attempting to set an object's ACL to a different value from its parent will result in a 403 Forbidden error.
Backblaze B2 features slightly different restrictions on file and bucket names than Amazon S3.
Buckets in Backblaze B2 are versioned by default. Because Buckets are versioned, when a file is deleted by referencing the name only the most recent version of that file will be deleted and older versions of the file will continue to exist in the Bucket.
The API endpoints only accept connections over HTTPS. Non-secure connections will be rejected.
Backblaze B2 supports server-side encryption of data using either Backblaze-managed keys (SSE-B2) or using customer-managed keys (SSE-C). SSE-KMS encryption is not currently supported.
IAM roles, Object Tagging, Bucket Logging, Website configuration, and Lifecycle Rules are not currently supported.

For a more detailed explanation of the differences between the Backblaze B2 Cloud Storage S3 Compatible API and Amazon S3 see the Backblaze B2 S3 Compatible API documentation.