Skip to main content
GET
Get S3 Storage

Overview

Returns the S3-compatible storage configuration currently saved for your API key — whatever was last set via POST /user/s3 (or the deprecated /user/bucket endpoint). Use this to confirm what’s configured, or to check whether a key has any custom storage at all, without needing to run a test job.
If nothing is configured, this returns 200 OK with "configured": false — not an error. A key with no custom storage is a normal state; it simply falls back to Tornado’s managed storage.
This endpoint never returns your secret_key, and never returns a full access_key — see Security below.

Header Parameters

string
required
Your API key for authentication

Response

boolean
Whether this key has any S3 storage configured. All other fields are only present when true.
string
Storage provider type: s3
string
The configured bucket name
string
The configured folder prefix, if any
string
The configured base folder (only present when set via the modern /user/s3 path)
string
The configured S3 endpoint URL. Only present in legacy mode (the source field below explains the difference) — the modern, Key Vault-backed path doesn’t hold the endpoint outside the vault.
string
The configured region. Only present in legacy mode.
string
The last 4 characters of your access key ID, prefixed with **** (e.g. ****MPLE). Only present in legacy mode. Never the full key — see Security.
integer
Unix timestamp (seconds) of when this configuration was last saved. Only present in modern (Key Vault) mode.
string
Which storage location this configuration came from:
  • keyvault — saved via POST /user/s3 with Key Vault enabled (the default, modern path). Credentials live in Azure Key Vault; this service never holds them outside of upload time, so endpoint, region, and access_key_masked aren’t available to return.
  • legacy — saved via the fallback path used when Key Vault is disabled (or the deprecated /user/bucket endpoint). Credentials are stored on the API key document; access_key is shown masked, secret_key is never returned.
If both happen to exist for a key, keyvault always wins — this matches exactly which one is actually used for uploads.

Examples

Success Response

Error Responses

Security

There is no secret_key or secret_key_masked field in the response at all, in either mode. It’s write-only from the API’s perspective — set it via POST /user/s3, but it can never be read back.
In legacy mode, only the last 4 characters are returned (access_key_masked, e.g. ****MPLE). Values 4 characters or shorter are fully masked (****) rather than echoed whole. In Key Vault mode, the access key isn’t returned at all — this service doesn’t hold it outside of upload time.
The internal Key Vault secret name (an infrastructure detail, not a credential, but still sensitive) is never included in the response.

Checking Configuration Programmatically

Configure S3 Storage

Set or update your S3-compatible storage configuration

Remove S3 Storage

Remove your S3 configuration and revert to Tornado’s managed storage