S3 API Compatibility

This page documents S3 APIs supported by MinIO AIStor. For reference documentation on any given API, see the corresponding documentation for Amazon S3.

Object APIs

Conditional headers

MinIO AIStor supports conditional operations using the following HTTP headers:

Header Supported operations
If-Match GetObject, HeadObject, PutObject, CopyObject, DeleteObject, CreateMultipartUpload
If-None-Match GetObject, HeadObject, PutObject, CopyObject, CreateMultipartUpload
If-Modified-Since GetObject, HeadObject
If-Unmodified-Since GetObject, HeadObject
x-amz-copy-source-if-match CopyObject, UploadPartCopy
x-amz-copy-source-if-none-match CopyObject, UploadPartCopy
x-amz-copy-source-if-modified-since CopyObject, UploadPartCopy
x-amz-copy-source-if-unmodified-since CopyObject, UploadPartCopy

DeleteObjects supports conditional deletes using the <ETag> element in the request body.

Object locking

Unsupported object APIs

  • GetObjectAcl
  • PutObjectAcl

Multipart uploads

Differences from S3 APIs for multipart uploads

  • ListMultipartUploads requires the exact object name as a prefix.

  • The AbortIncompleteMultipartUpload lifecycle action is not supported with PutBucketLifecycle.

Bucket APIs

Bucket replication

Bucket lifecycle

Bucket notifications

Bucket policies

Unsupported bucket API operations

  • GetBucketInventoryConfiguration
  • PutBucketInventoryConfiguration
  • DeleteBucketInventoryConfiguration
  • GetBucketMetricsConfiguration
  • PutBucketMetricsConfiguration
  • DeleteBucketMetricsConfiguration
  • PutBucketWebsite
  • GetBucketLogging
  • PutBucketLogging
  • PutBucketAccelerateConfiguration
  • DeleteBucketAccelerateConfiguration
  • PutBucketRequestPayment
  • DeleteBucketRequestPayment
  • PutBucketAcl
  • HeadBucketAcl
  • GetPublicAccessBlock
  • PutPublicAccessBlock
  • DeletePublicAccessBlock
  • GetBucketOwnershipControls
  • PutBucketOwnershipControls
  • DeleteBucketOwnershipControls
  • GetBucketIntelligentTieringConfiguration
  • PutBucketIntelligentTieringConfiguration
  • ListBucketIntelligentTieringConfigurations
  • DeleteBucketIntelligentTieringConfiguration
  • GetBucketAnalyticsConfiguration

MinIO AIStor alternatives for unsupported bucket API operations

  • For calls to BucketACL or ObjectACL operations, use Policies.
  • For calls to BucketWebsite operations, use caddy or nginx.
  • For calls to BucketAnalytics, BucketMetrics, or BucketLogging operations, use Bucket notifications.

S3 extensions

MinIO AIStor extends the S3 API with additional capabilities, including Object Lambda for on-the-fly object transformation during retrieval and the S3 ZIP Extension for reading individual files inside ZIP archives without extracting them first.

S3 over RDMA

On a deployment running the RDMA build, GetObject, PutObject, and UploadPart can transfer object data directly between client memory and the server over RDMA, using the AWS S3 RDMA protocol. GetObject writes into the client’s buffer; PutObject and UploadPart read from it. That buffer is usually GPU memory, which is where RDMA pays off most, but host memory works too and needs no GPU.

The client opts in per request with a header; there is no server setting.

Header Direction Description
x-amz-rdma-token Request The client’s RDMA buffer descriptor.
x-amz-rdma-reply Response 200 or 206 when the transfer used RDMA, 501 when the server declined.
x-amz-rdma-bytes-transferred Response Bytes transferred out of band, when non-zero.

On a successful RDMA transfer the server sets Content-Length: 0, because the object bytes did not travel in the HTTP response.

When the server declines, it returns an S3 error response rather than serving the object over HTTP. Retrying without the x-amz-rdma-token header is the client’s responsibility. The MinIO SDKs below handle this automatically.

Reliable Connection clients first perform a handshake at POST /rdma/connect, exchanging descriptors through the same x-amz-rdma-token header. Dynamically Connected clients do not use this route.

SDK support

S3 over RDMA is supported by the MinIO SDKs for Go, C++, Rust, and Python.

Each of them uses NVIDIA cuObjClient to move the object payload between GPU memory and the network adapter.

For worked examples in each language, see Transfer Objects over RDMA.

For deployment, see RDMA acceleration.

S3 Express mode

When MinIO AIStor runs in S3 Express mode, the supported S3 API surface differs from the default S3 API mode. S3 Express mode also adds the AppendObject behavior, which lets a client append data to an existing object by issuing a PutObject request with the x-amz-write-offset-bytes header. For the list of operations supported and disabled in S3 Express mode, see S3 Express mode.

MinIO-specific error codes

In addition to the standard S3 error codes, MinIO AIStor returns the following MinIO-specific error codes:

Code HTTP status Description
NotSupported 501 API operation not implemented.
NotImplemented 501 KMS not configured or feature unavailable.
XMinioHealNotImplemented 400 Healing not available in this mode.
XMinioLDAPNotEnabled 501 LDAP must be enabled for this operation.
InvalidToken 400 Object Lambda output token mismatch.
LambdaFunctionStatusError 400 Object Lambda function returned an invalid status.
RDMATransferError 503 An S3-over-RDMA transfer failed. Retry the request, without the x-amz-rdma-token header to fall back to HTTP.

KMS error codes

KMS-backed operations return these codes, including when the KMS itself is unreachable:

Code HTTP status Description
kms:NotAuthorized 403 The KMS credentials lack permission for the operation.
kms:KeyNotFound 404 No key exists with the given key ID.
kms:KeyAlreadyExists 409 A key already exists with the given key ID.
kms:InvalidCiphertextException 400 The ciphertext could not be decrypted. The key material does not match.
kms:DecryptionFailed 503 The decryption request could not be completed at all, for example because the KMS was unreachable. Unlike kms:InvalidCiphertextException, this does not imply invalid ciphertext. Retry the request.
kms:NotSupported 501 The configured KMS does not support the requested functionality.
kms:KeyCreationFailed 503 The KMS could not create the key.
kms:KeyDeletionFailed 503 The KMS could not delete the key.
kms:KeyListingFailed 503 The KMS could not list keys.
kms:KeyGenerationFailed 503 The KMS could not generate a data key.

A request that the client cancels while a KMS operation is in flight returns status 499 rather than a KMS error.

Changed in RELEASE.2026-08-07T18-34-35Z

A KMS-backed request previously returned 500 whatever the cause. It now returns 503 when the KMS is unreachable, which distinguishes a retryable outage from an invalid ciphertext, and 499 when the client cancels the request.

Update any client retry logic or alerting rule that keys on a 500 response to a KMS-backed operation.