Introduction

Availability

Early Access: July 1, 2026

Early Access is gated; contact the Backblaze Sales team for access.

Limited Availability: July 1, 2026

This API is available only to customers with access to the Backblaze Enterprise Web Console. For more information, contact the Backblaze Sales team.

The Backblaze IAM and STS API can be used to manage AWS-compatible identity and access management resources, such as IAM users, IAM roles, inline policies, access keys, temporary credentials, and bucket policies. The API is designed to work with common AWS tools and SDKs when configured to use the appropriate Backblaze IAM, STS, or S3-compatible endpoint.

Using the Backblaze IAM and STS API, you can:

• Create, list, and delete IAM users and IAM roles

• Add, list, and delete inline policies on users and roles

• Create, update, list, and delete access keys for IAM users

• Issue short-lived temporary security credentials with AssumeRole

• Identify the caller using GetCallerIdentity

• Add, retrieve, and delete bucket policies through the S3-compatible API

Prerequisites

To get started, you need access to the Backblaze Enterprise Web Console and credentials with the permissions required for the IAM or STS operations that you want to perform.

For more information about access, contact the Backblaze Sales team.

Authentication

All IAM and STS requests must be signed using AWS Signature Version 4. Required headers include:

Content-Type: application/x-www-form-urlencoded; charset=utf-8
Host: <service-endpoint>
X-Amz-Date: YYYYMMDD'T'HHMMSS'Z'
Authorization: AWS4-HMAC-SHA256 Credential=..., SignedHeaders=..., Signature=...

Set the Host header to the endpoint for the service that you are calling.

The SigV4 signing region is not validated. You can use any non-empty region value as long as you use it consistently when signing the request. Use iam as the signing service for IAM requests and sts as the signing service for STS requests.

When using temporary credentials issued through AssumeRole, also include the X-Amz-Security-Token header with the session token.

API Base URLs

The Backblaze IAM and STS API uses distinct endpoints for different service categories:

Regional STS endpoints are not currently supported. Bucket policy requests must be sent to the S3-compatible endpoint for the region that contains the bucket.

Request and Response Formats

The Backblaze IAM and STS API uses the AWS Query API model. All IAM and STS operations support POST /, with an Action parameter in the form-encoded body:

POST / HTTP/1.1
Host: iam.backblazeb2.com
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Action=CreateRole&Version=2010-05-08&RoleName=example-role&...

Selected read-only operations also support GET with the same parameters supplied in the query string.

IAM and STS responses are XML documents that follow AWS IAM and STS response conventions. Bucket policy operations are served through the S3-compatible API and follow S3-compatible request and response conventions.

Status Codes

For calls to the Backblaze IAM and STS API, the HTTP status code that is returned indicates success or failure. A status of 200 (OK) means success. Bucket policy operations may return 204 (No Content). Any code in the 400 or 500 range is a failure. The API does not use redirects (status codes in the 300 range).

Error Structure

Failures are returned as XML documents with a Type, Code, and Message, along with a top-level RequestId. Include the RequestId value when contacting support so the request can be correlated with server-side traces.

HTTP Status Codes

XML Error Structure

The following example shows an XML error response:

<ErrorResponse xmlns="https://iam.amazonaws.com/doc/2010-05-08/">
    <Error>
        <Type>Sender</Type>
        <Code>ValidationError</Code>
        <Message>Invalid RoleName</Message>
    </Error>
    <RequestId>req-1234567890</RequestId>
</ErrorResponse>

API Versions

Release Timeline

The Backblaze IAM and STS API reaches production in two waves.

The initial production release on September 30, 2026 includes AssumeRole, CreateRole, all User and User Policy operations, and all Access Key operations.

A second production release on November 5, 2026 adds GetCallerIdentity, Role Policy operations, ListRoles, DeleteRole, and all Bucket Policy operations. Operations in the second wave display an Available Nov 5, 2026 badge in the API reference.

Bucket policy enforcement also begins November 5, 2026. Before that date, bucket policies set through the API are stored but not applied.

Feature Scope

Backblaze IAM intentionally supports a reduced feature set in the first release. Managed policies, policy attachments, permissions boundaries, resource tagging on IAM resources, and regional STS endpoints are not supported.

Policies are supported only as inline role policies, inline user policies, session policies passed to AssumeRole, and bucket policies.

For launch, supported policy conditions include IpAddress, NotIpAddress, and the aws:SourceIp condition key, including IPv4 and IPv6 CIDR matching.

Backblaze IAM is eventually consistent. Changes to users, roles, policies, access keys, and bucket policies may take a short amount of time to propagate.

STS credentials represent a snapshot of permissions at the time the session is issued. Policy changes made after an STS session is created do not change the permissions for that existing session. The changes apply only to newly issued sessions.