Everything an AI agent can do with the Backblaze B2 API.

A reference guide for building AI agents: every method, how to authenticate, and the permissions each one needs.

Endpoints27
API versionv3
Last updated23 June 2026
Orientation

How the Backblaze B2 API works.

The Backblaze B2 API is how an app or AI agent works with B2 cloud storage: uploading and downloading files, listing and deleting their versions, creating and managing buckets, and minting application keys. Access is granted through an application key that carries a set of capabilities, like listBuckets or writeFiles, and a key can be limited to a single bucket and a single file name prefix. Backblaze B2 can also push an event to a webhook when a file is created, deleted, or hidden in a bucket.

27Endpoints
6Capability groups
11Read
16Write
12Permissions
Authentication
Every B2 Native API call starts at b2_authorize_account, which takes an application key (a keyID and applicationKey) over HTTP Basic auth and returns an authorization token plus the base URL to use for later calls. That token goes in the Authorization header on every other request and is short-lived, so an expired_auth_token is the normal signal to authorize again. The master application key created with the account has every capability and cannot be restricted; Backblaze recommends a scoped application key for day-to-day work.
Permissions
An application key carries a set of capabilities, each a short token, like listBuckets, readBuckets, writeBuckets, deleteBuckets, listFiles, readFiles, writeFiles, deleteFiles, shareFiles, listKeys, writeKeys, deleteKeys, and readBucketNotifications or writeBucketNotifications. A key can also be restricted to a single bucket and a single file name prefix, so it reaches only files whose name starts with that prefix. A new key can hold no more capabilities than the key that created it, and a 403 access_denied means the key lacks the capability or bucket the call needs.
Versioning
The B2 Native API is versioned by a number in the request path, like v3 in /b2api/v3/. v3, from September 2021, reworked b2_authorize_account to report access across several API suites at once, and the newer v4, from April 2025, added application keys that span a chosen group of buckets. Backblaze keeps older versions working and has no plans to remove them, so an integration pins a version and upgrades on its own schedule.
Data model
B2 is object storage: buckets hold files, and every file keeps its versions until a lifecycle rule or an explicit delete removes them. A file is uploaded in one request up to 5 GB, or split into up to 10,000 parts for a large file. Hiding a file adds a hide marker so a download by name skips it without erasing earlier versions. The same buckets are reachable through an S3-compatible API, and a bucket can push an event to a webhook when its files change.
Connect & authenticate

Connection & authentication methods.

How an app or AI agent connects to Backblaze B2 determines what it can reach. There is the B2 Native API for storage operations, an S3-compatible API for tools that already speak S3, and event notifications for receiving activity, each governed by the application key behind it and the capabilities that key carries.

Ways to connect

B2 Native API

The B2 Native API is Backblaze's own storage API. A call first hits b2_authorize_account with the application key over HTTP Basic auth, which returns an authorization token and the base URL to send every later request to. The version is a number in the path, like v3.

Best forConnecting an app or AI agent to Backblaze B2.
Governed byThe application key and the capabilities it carries.
Docs ↗

S3-compatible API

Backblaze B2 also exposes an S3-compatible API, so tools and libraries built for Amazon S3 can read and write B2 buckets with little change. It uses the same application keys as the Native API.

Best forReusing existing S3 tooling against Backblaze B2.
Governed byThe application key and the capabilities it carries.
Docs ↗

Event notifications (webhooks)

Event notifications POST a JSON payload to a webhook URL when a file is created, deleted, or hidden in a bucket. A rule can set an hmacSha256SigningSecret, and each delivery then carries an X-Bz-Event-Notification-Signature header so the receiver can confirm it came from Backblaze.

Best forReceiving Backblaze B2 activity at an app or AI agent.
Governed byThe signing secret on the notification rule.
Docs ↗
Authentication

Application key

An application key is a keyID and applicationKey pair sent to b2_authorize_account with HTTP Basic auth. The key carries a set of capabilities, like listBuckets, readFiles, or writeFiles, and can be limited to a single bucket and a single file name prefix. The authorize call returns a short-lived token used for every other request.

TokenApplication key (keyID + applicationKey)
Best forServer-side access scoped to specific capabilities, a bucket, and a prefix.
Docs ↗

Master application key

The master application key is the account-wide key created with the account. It carries every capability across all buckets and cannot be restricted, so Backblaze recommends a scoped application key for day-to-day work.

TokenMaster application key (keyID + applicationKey)
Best forAccount administration and creating restricted keys.
Docs ↗
Endpoint reference

Every Backblaze B2 API method.

Filter by method, access, or permission, or search any path. Select a row for version detail, rate limits, the related webhook event, and the source.

MethodEndpointWhat it doesAccessPermissionVersion

Authorization

Exchange an application key for an authorization token and the base URL to use for every later call.1

The only call that uses HTTP Basic auth with the keyID and applicationKey; no capability is needed to call it. The response reports the capabilities, buckets, and name prefix the key is allowed.

Acts onaccount
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Buckets

Create, list, update, and delete the buckets that hold files.4

The token must have the writeBuckets capability.

Acts onbucket
Permission (capability)writeBuckets
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The token must have the listBuckets capability. A key restricted to one bucket lists only that bucket.

Acts onbucket
Permission (capability)listBuckets
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The token must have the writeBuckets capability.

Acts onbucket
Permission (capability)writeBuckets
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The token must have the deleteBuckets capability. The bucket must be empty.

Acts onbucket
Permission (capability)deleteBuckets
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Files

Upload, list, get metadata for, download, copy, hide, and delete files.10

The token must have the writeFiles capability. The returned upload URL points at a specific pod and is used by b2_upload_file.

Acts onupload URL
Permission (capability)writeFiles
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Sent to the upload URL from b2_get_upload_url, not the main API host, with that call's writeFiles authorization. Files over 5 GB use the large-file flow.

Acts onfile
Permission (capability)writeFiles
VersionAvailable since the API’s base version
Webhook eventobject_created_upload
Rate limitStandard limits apply

The token must have the listFiles capability. Returning more than 1,000 files in one call counts as multiple class C transactions.

Acts onfile
Permission (capability)listFiles
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit1 class C transaction per 1,000 files returned

The token must have the listFiles capability. Returning more than 1,000 entries in one call counts as multiple class C transactions.

Acts onfile version
Permission (capability)listFiles
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit1 class C transaction per 1,000 entries returned

The token must have the readFiles capability.

Acts onfile
Permission (capability)readFiles
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The token must have the readFiles capability for a private bucket. Served from the download host, not the main API host. A public bucket needs no token.

Acts onfile
Permission (capability)readFiles
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The token must have the readFiles capability for a private bucket. Served from the download host.

Acts onfile
Permission (capability)readFiles
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The token must have the writeFiles capability, and readFiles if the source bucket is private.

Acts onfile
Permission (capability)writeFiles
VersionAvailable since the API’s base version
Webhook eventobject_created_copy
Rate limitStandard limits apply

The token must have the writeFiles capability.

Acts onfile
Permission (capability)writeFiles
VersionAvailable since the API’s base version
Webhook eventhide_marker_created
Rate limitStandard limits apply

The token must have the deleteFiles capability. An older version may become current when the latest is removed.

Acts onfile version
Permission (capability)deleteFiles
VersionAvailable since the API’s base version
Webhook eventobject_deleted
Rate limitStandard limits apply

Large files

Start a multi-part upload, upload each part, then finish or cancel it.7

The token must have the writeFiles capability.

Acts onlarge file
Permission (capability)writeFiles
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The token must have the writeFiles capability. The returned URL points at a specific pod and is used by b2_upload_part.

Acts onupload URL
Permission (capability)writeFiles
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Sent to the upload URL from b2_get_upload_part_url, not the main API host, with that call's writeFiles authorization.

Acts onlarge file part
Permission (capability)writeFiles
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The token must have the writeFiles capability.

Acts onlarge file
Permission (capability)writeFiles
VersionAvailable since the API’s base version
Webhook eventobject_created_multipart
Rate limitStandard limits apply

The token must have the writeFiles capability.

Acts onlarge file
Permission (capability)writeFiles
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The token must have the writeFiles capability, the same one that uploads the parts, not listFiles.

Acts onlarge file part
Permission (capability)writeFiles
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The token must have the listFiles capability.

Acts onlarge file
Permission (capability)listFiles
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Application keys

Create, list, and delete the application keys that grant access to the account.3

The token must have the writeKeys capability. A new key can carry no more capabilities than the key that created it. The secret key is returned only once.

Acts onapplication key
Permission (capability)writeKeys
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The token must have the listKeys capability. The list never includes the secret part of a key.

Acts onapplication key
Permission (capability)listKeys
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The token must have the deleteKeys capability.

Acts onapplication key
Permission (capability)deleteKeys
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Event notifications

Read and set the rules that send a webhook when files change in a bucket.2

The token must have the writeBucketNotifications capability. A rule can set an HMAC signing secret so the receiver can verify each webhook.

Acts onnotification rule
Permission (capability)writeBucketNotifications
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

The token must have the readBucketNotifications capability. The response includes whether a rule is suspended and why.

Acts onnotification rule
Permission (capability)readBucketNotifications
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply
No endpoints match those filters.
Webhooks

Webhook events.

Backblaze B2 can notify an app or AI agent when something happens in a bucket, like a file being uploaded, deleted, or hidden. It sends an HTTP POST with a JSON payload to a webhook URL set on a notification rule, so an integration learns about activity without polling.

EventWhat it signalsTriggered by
b2:ObjectCreated:UploadFires when an object is created by uploading a file with b2_upload_file./b2api/v3/b2_upload_file
b2:ObjectCreated:MultipartUploadFires when an object is created by finishing a large, multi-part upload./b2api/v3/b2_finish_large_file
b2:ObjectCreated:CopyFires when an object is created by a server-side copy with b2_copy_file./b2api/v3/b2_copy_file
b2:ObjectDeleted:DeleteFires when a file version is deleted by a user with b2_delete_file_version./b2api/v3/b2_delete_file_version
b2:HideMarkerCreated:HideFires when a hide marker is created by a user with b2_hide_file./b2api/v3/b2_hide_file
No events match that search.
Rate limits & pagination

Rate limits, pagination & request size.

Backblaze limits how fast an app or AI agent can call on a per-account basis, and large transfers are split into parts rather than sent in one request.

Request rate

Backblaze states that B2 may limit API requests on a per-account basis, returning HTTP 429 too_many_requests when a limit is hit, with a Retry-After header to honor where present. A 503 service_unavailable points at a busy upload pod rather than the account, and the documented fix is to retry with exponential backoff, requesting a fresh upload URL from b2_get_upload_url before retrying an upload. Backblaze does not publish a fixed requests-per-second number for the Native API. A separate billing model counts each call as a class A, B, or C transaction, and a single list call that returns more than 1,000 files is billed as several class C transactions.

Pagination

List calls page forward with a continuation token in the response. b2_list_file_names and b2_list_file_versions return up to maxFileCount entries, which defaults to 100 and tops out at 10,000, and a nextFileName in the response is passed back as startFileName to fetch the next page, or is null when the list is exhausted. The large-file and key list calls follow the same next-token pattern with their own fields.

Request size

A single b2_upload_file request uploads a file up to 5 GB. A larger file uses the large-file flow: b2_start_large_file, then b2_upload_part for each part numbered 1 to 10,000, then b2_finish_large_file. A list call returns at most 1,000 entries per billed transaction, even when maxFileCount is set higher.

Errors

Status codes & error handling.

The status codes an agent should handle, and what to do about each.

StatusCodeMeaningWhat to do
400bad_requestThe request had bad parameters, like an invalid bucket name or a missing field. The code names the specific problem.Read the message, fix the named parameter, and resend. The request is not retryable as-is.
401unauthorized / bad_auth_token / expired_auth_tokenAuthentication failed: the application key is wrong, the authorization token is invalid, or the token has expired.Call b2_authorize_account again to get a fresh token, then retry. An expired_auth_token is the normal signal to re-authorize.
403transaction_cap_exceeded / access_deniedThe account hit a usage cap, or the key lacks the capability or bucket access the request needs.Raise the cap in the account, or grant the missing capability or bucket on the key, then retry.
404not_foundThe requested bucket, file, or key does not exist or is not visible to this key.Confirm the identifier and that the key can reach the resource, then retry.
408request_timeoutThe request took too long to complete on the server side.Retry the request, splitting a large upload into parts if needed.
429too_many_requestsB2 is limiting requests on a per-account basis because too many arrived too quickly.Honor the Retry-After header when present, then retry with backoff and a lower request rate.
500internal_errorAn error on Backblaze's side while handling the request.Retry with exponential backoff. For an upload, get a fresh upload URL first.
503service_unavailableThe service is temporarily unavailable, often a busy upload pod.Retry with exponential backoff, and for an upload request a new upload URL from b2_get_upload_url first.
Versioning & freshness

Version history.

Backblaze versions the B2 Native API by a number in the request path. v3 reworked how authorization reports access across multiple API suites, and the newer v4 added application keys that span several buckets.

Version history

What changed, and when

Latest versionv3
v4
Multi-bucket application keys

v4 added the ability to create application keys that grant access to a chosen group of buckets within an account, with an optional file prefix restriction, through a new bucketIds field on b2_create_key. The b2_authorize_account response moved bucket restriction details into an allowed object holding buckets, capabilities, and namePrefix. A v4 key with no bucket restriction still works with v3 b2_authorize_account. It was released on 29 April 2025.

What changed
  • b2_create_key gained a bucketIds field for multi-bucket keys, replacing the single bucketId
  • b2_authorize_account moved bucket restriction fields into an allowed object
  • Optional single-prefix restriction supported on multi-bucket keys
v3Current version
Multi-suite authorization (current pinned version)

v3 reworked b2_authorize_account to report access across multiple API suites, including the B2 Storage and Partner APIs, grouping the returned information by suite rather than as a single flat response. It was released on 23 September 2021.

What changed
  • b2_authorize_account extended to describe access across several API suites
  • Returned account information grouped by API suite
v2
Application key cleanup

v2 cleaned up the application key behavior introduced in 2018 for restricted keys. Later additive updates on v2 added server-side encryption fields in March 2021 and Object Lock fields in May 2021. It was released on 13 September 2018.

What changed
  • Cleaned up the restricted application key workaround from August 2018
  • Server-side encryption fields added (March 2021)
  • Object Lock information fields added (May 2021)
v1
Original release

v1 launched with the B2 Cloud Storage service. Later additive updates added application key management in July 2018 and adjusted behavior for restricted keys in August 2018. It was released on 22 September 2015.

What changed
  • Launched the B2 Native API with the B2 service
  • Application key management added (July 2018)
  • Restricted key behavior adjusted (August 2018)

An integration can pin a version in the path and move up on a schedule that suits it.

B2 Native API version history ↗
Questions

Backblaze B2 API, answered.

How does authentication work, and why does my token stop working?+
A call to b2_authorize_account sends the application key (keyID and applicationKey) using HTTP Basic auth and gets back an authorization token and the base URL for later calls. That token is short-lived, so a request can later fail with a 401 expired_auth_token. The fix is to call b2_authorize_account again for a fresh token, which is the expected pattern rather than an error in the integration.
What can an application key be restricted to?+
A key holds a chosen set of capabilities, like readFiles or writeFiles, and can also be limited to one bucket and one file name prefix. With a prefix set, the key reaches only files whose name starts with that prefix, so a key can be scoped to a single folder-like path within a bucket. A new key can never be granted more capabilities than the key that created it.
How do I upload a file larger than 5 GB?+
A single b2_upload_file request handles a file up to 5 GB. A larger file uses the large-file flow: b2_start_large_file to begin, b2_get_upload_part_url and b2_upload_part for each part numbered 1 to 10,000, then b2_finish_large_file to combine them, or b2_cancel_large_file to abandon the upload and delete the parts already sent.
What are the rate limits, and how should retries work?+
Backblaze does not publish a fixed requests-per-second figure; it states that B2 may limit requests on a per-account basis and returns HTTP 429 too_many_requests when it does, with a Retry-After header to honor where present. A 503 service_unavailable usually means a busy upload pod rather than the account. The documented approach is exponential backoff, and for an upload, requesting a fresh upload URL before retrying.
Can Backblaze B2 notify me when a file changes instead of polling?+
Yes. Event notifications send an HTTP POST with a JSON payload to a webhook URL when a file is created, deleted, or hidden in a bucket, with event types like b2:ObjectCreated:Upload and b2:ObjectDeleted:Delete. Rules are set with b2_set_bucket_notification_rules. A rule can carry an HMAC signing secret, and each delivery then includes an X-Bz-Event-Notification-Signature header the receiver checks to confirm it came from Backblaze.
What is the difference between the Native API and the S3-compatible API?+
The B2 Native API is Backblaze's own API, reached after b2_authorize_account, and it exposes B2 features directly. The S3-compatible API lets tools and libraries written for Amazon S3 work against B2 buckets with little change. Both read and write the same buckets and use the same application keys, so the choice is mainly which one existing tooling already speaks.
What happens when I delete or hide a file?+
b2_delete_file_version removes one specific version of a file by its name and file ID; if that version was the current one, an older version can become current. b2_hide_file instead adds a hide marker so a download by name no longer finds the file, while every earlier version is preserved and still reachable by file ID. Deleting every version removes the file entirely.
Related

More storage API guides for agents

What is Bollard AI?

Control what every AI agent can do in Backblaze B2.

Bollard AI sits between a team's AI agents and Backblaze B2. Grant each agent exactly the access it needs, read or write, bucket by bucket, and every call is checked and logged.

  • Set read, write, or full access per agent, never a shared Backblaze key.
  • Denied by default, so an agent reaches only what has been explicitly allowed.
  • Every call recorded in plain English: who, what, where, and the decision.
Backblaze B2
Backup Agent
List files ActionOffReadFull use
Upload files ActionOffReadFull use
Delete files ActionOffReadFull use
Application keys ResourceOffReadFull use
Per-agent access, set in Bollard AI, not in Backblaze B2