Backblaze B2

B2 offers two API paths: the native B2 API and the S3-compatible gateway. The native API uses authorization tokens obtained via b2_authorize_account, then operates via URLs returned in that auth response — a pattern that feels more session-oriented than REST-idiomatic. Large file uploads use a start/part/finish protocol similar to S3 multipart. The S3 compat layer at s3.us-west-004.backblazeb2.com handles standard CRUD well but doesn't support all S3 features (no transfer acceleration, no object lock via S3 API). List operations work but pagination uses nextFileName rather than ContinuationToken on the native API. Agents should prefer the S3 compat layer unless they need native-only features.

The native B2 API returns JSON errors with status, code, and message fields — clean and parseable. Common error codes: bad_auth_token (expired token, re-authorize), cap_exceeded (rate limit), service_unavailable (retry with backoff). The S3 compat layer returns standard S3-format XML errors. Rate limits are not published with specific numbers; the documentation says to implement exponential backoff when receiving 429 or 503 responses. B2's durability guarantee is 11 nines (same as S3). The main reliability concern for agents is the single-region architecture — no multi-region replication option means a regional outage affects all data. Upload retry on large files is well-documented.

B2's primary appeal for agents is economics: storage at roughly 1/4 the cost of S3 Standard, with free egress to Cloudflare partners via the Bandwidth Alliance. The S3-compatible gateway means agents using AWS SDKs can switch to B2 by changing the endpoint URL. The native B2 API offers features the S3 compat layer doesn't expose (like server-side copy across buckets). For agent workloads that are storage-heavy and latency-tolerant — backup, archive, asset storage — B2 is a rational choice. Limitations include a single data center region (US West or EU Central, chosen at bucket creation), fewer storage classes, and no event notification system comparable to S3's.

Application keys are the primary credential mechanism. Master application keys have full account access; agents should use non-master keys scoped to specific buckets and permissions (read, write, list, delete). Key creation returns a keyId and applicationKey pair that maps cleanly to S3's access key / secret key model. Key rotation requires creating a new key and deleting the old one — no automatic rotation. There's no equivalent to STS temporary credentials. CORS rules are per-bucket. The auth model is simpler than IAM but less flexible — no policy documents, no condition-based access, no resource-level permissions beyond bucket scope.

Documentation is practical and well-structured, though significantly smaller in scope than S3 or GCS docs. The native B2 API reference is clear with working curl examples. The S3 compat guide explicitly lists supported and unsupported S3 operations — essential for agents evaluating compatibility. The b2 CLI tool provides file management and account operations. Community SDK support is thinner than S3 — the official Python SDK (b2sdk) is maintained but third-party integrations are fewer. Migration guides from S3 exist but are light on edge cases. Dashboard is functional for bucket management and key creation. Overall: adequate for agent setup, but agents encounter undocumented edge cases more often than with S3 or GCS.