S3 Access Keys

S3 access keys are access-key/secret pairs, created from the dashboard's Access Keys page. A key belongs either to you or to a team. One key pair authenticates two ways:

• SigV4 on the S3-compatible endpoint — standard AWS tooling (SDKs, aws s3, rclone) and AWS presigners work against your bucket hostnames.
• HTTP Basic auth against this API — Authorization: Basic base64(access_key_id:secret) on any RPC, handy for scripts and CI without an OAuth flow.

Key format

The secret is generated server-side and shown exactly once, when the key is created or rotated. It cannot be retrieved again — store it in a secret manager, ~/.aws/credentials, or your CI's secret store.

Who owns a key

A team key belongs to the team rather than to whoever created it, so it keeps working after that person leaves — which is the point of using one for CI and other shared automation.

Ownership is a hard boundary in both directions:

• a personal key can only be granted buckets you own;
• a team key can only be granted buckets owned by that same team.

So if you need to automate against a team's bucket, create a team key. A personal key will be refused, even if you are an admin of the team and could reach the bucket yourself in the dashboard.

Moving a bucket between owners revokes any key grants that would end up on the wrong side of that boundary; the dashboard names the affected keys before the move goes ahead.

Grants and permissions

A key optionally carries per-bucket grants, each at read or read-write level:

• With grants — the key can only act on the granted buckets, at the granted level.
• Without grants — the key acts on all buckets you can access, at your own permission level.

For a team key, "without grants" means every bucket that team owns — evaluated at request time, so a bucket the team gains later is covered without reissuing the key.

Two ceilings always apply, regardless of grants:

1. A key can never exceed its owner's live permissions — if access to a bucket is revoked, every key's access to it ends at the same moment. For a team key the ceiling is read-write on the team's own buckets.
2. Keys are capped below admin by default: they can read and write content, but cannot manage buckets, permissions, or other access keys. A key can be given an admin grant on a specific bucket, which additionally allows configuring that bucket'"'"'s CORS and policy over the S3 API. Admin is per-bucket and never implied — a key with no grants never has it.

Basic auth against the API

Use the access key ID as the username and the secret as the password:

curl -u UPL4K7Q2M9XR5TB0WNZH:uplSECRET \
  -H 'Content-Type: application/json' \
  -d '{}' \
  https://uploads-api.xeonr.io/uplim.api.v1.BucketsService/ListBuckets

Requests authenticate as you, constrained by the key's grants. Operations outside the key's grants return permission_denied; bucket-management and key-management RPCs are always denied for key-authenticated callers.

Rotate and revoke

• Rotate replaces the secret in place: the access key ID, label, grants, and usage history are preserved, and the old secret stops working immediately. Use it when a secret may have leaked.
• Revoke permanently deletes the key. This cannot be undone. For gradual migration, create a second key, move consumers over, then revoke the old one.
• Disable pauses a key reversibly — authentication fails until it's re-enabled.

Revocation and rotation take effect immediately for Basic auth. S3-endpoint traffic observes them within at most 60 seconds.

The last used timestamp on each key is updated lazily (at most every few minutes), and for S3-endpoint traffic reflects gateway cache refreshes rather than every request.

S3 endpoint

See the S3-Compatible API for SigV4, presigned URLs, and aws CLI / rclone configuration.