API Keys

API keys authenticate your requests to the Fil One S3 API. Each key consists of an Access Key ID (public identifier) and a Secret Access Key (used to sign requests).

Creating an API key

1. Go to API Keys in the left menu of the dashboard.
2. Click Create new key (this opens a dedicated page).
3. Give the key a descriptive name (e.g., production-backend, ci-pipeline). Names are limited to 64 characters (letters, numbers, spaces, and _ - .), and names starting with filone-console (in any capitalization) are reserved.
4. Choose the key's region (see Region scope). It is pre-set to eu-west-1, and it is fixed for the life of the key.
5. Set the key's permissions and bucket scope (see below). At least one permission is required, and you can only grant permissions your role holds (see Who can create and manage keys).
6. Optionally set an expiration: Never expires, 30 days, or a Custom date.
7. Click Create API key.
8. Copy the Secret Access Key immediately. It is shown only once. If you lose it, rotate the key to get a new one.

Key permissions

Object permissions

Each key can be granted a combination of the following object-level permissions:

Permission	What it allows
Read	GetObject (and HeadObject, which uses the same underlying permission), ListMultipartUploadParts. In us-east-1, also ListBucket
Write	PutObject, AbortMultipartUpload
List	ListObjectsV2 / ListBucket, and listing in-progress multipart uploads (ListBucketMultipartUploads)
Delete	DeleteObject

You can grant any combination of these permissions. A key with only Read and List permissions is suitable for read-only access, such as a CDN or analytics pipeline. A key with Write but not Delete can upload new objects and overwrite existing ones, but cannot delete them.

The Read grant differs by region. In us-east-1 it also includes ListBucket, so a key with Read but not List can still list object names there. In eu-west-1, Read does not include listing.

Listing the names of your buckets (ListAllMyBuckets) is granted to every key automatically and is not one of the permissions above. Note that the operator's documented Write grant covers PutObject and AbortMultipartUpload; the CreateMultipartUpload / UploadPart / CompleteMultipartUpload operations are not separately enumerated in the grant map.

Bucket management permissions

These are standalone permissions — they do not require any object permission. They can only be granted in regions where bucket management is available through the S3 API. In eu-west-1 they appear on the create form but are disabled, with the tooltip Not supported in Europe (France), so they cannot be granted on an eu-west-1 key. See Buckets.

Permission	What it allows
CreateBucket	Create a new bucket
DeleteBucket	Delete an empty bucket

Listing buckets is always permitted and is not a separate, configurable permission.

Bucket configuration permissions

These read a bucket's settings and are selectable in every region, including eu-west-1. The create form in the console pre-selects both, so untick them if your key doesn't need them.

Permission	What it allows
GetBucketVersioning	Read whether versioning is enabled on a bucket
GetBucketObjectLockConfiguration	Read a bucket's default Object Lock retention policy

Granular permissions

You can enable additional granular permissions on top of the basic object permissions. Each granular permission requires only its parent basic permission — the bucket does not need versioning or Object Lock enabled for the permission to be selectable:

Granular permission	Requires basic	What it allows
GetObjectVersion	Read	Retrieve specific versions of an object
GetObjectRetention	Read	View retention policy on an object
GetObjectLegalHold	Read	View legal hold status on an object
PutObjectRetention	Write	Apply or modify retention policies
PutObjectLegalHold	Write	Apply or remove legal holds
ListBucketVersions	List	List all versions of objects in a bucket
DeleteObjectVersion	Delete	Permanently delete a specific object version

Granular permissions are additive — a key must have the corresponding basic permission before a granular permission can be granted. For example, PutObjectRetention requires the Write basic permission.

PutObjectRetention and PutObjectLegalHold (Set retention and Set legal hold in the console) can only be granted by an Owner. For other roles, the create form doesn't show them.

note

Granting PutObjectRetention makes the permission available on the key. Per-object retention calls work in both regions. See S3 Compatibility.

note

GetObjectLegalHold and PutObjectLegalHold can be granted on a key. Legal Hold operations work through the S3 API in both regions. See S3 Compatibility.

Who can create and manage keys

A key can only carry permissions that your role in the organization holds, and the create form only offers those. What each role can do with keys:

• Read only members cannot create keys and don't see the key list.
• Members can create keys, and see, rotate, and delete only the keys they created.
• Admins and Owners can create keys and see, rotate, and delete every key in the organization.

Keys follow the person who created them. If a member's role is narrowed, any key they created that the new role couldn't create is revoked. Removing a member from the organization revokes the keys they created.

Region scope

Every key belongs to a single region, chosen when you create it. A key only authenticates requests to that region's endpoint — it cannot be used against another region, and it cannot be moved to one afterward. If you store data in both eu-west-1 and us-east-1, you need a separate key for each.

The region also determines which permissions are available: the bucket management permissions above cannot be granted on an eu-west-1 key.

Bucket scope

By default, a key has access to all buckets in your account. You can restrict a key to one or more specific buckets, which limits object operations to that set. Note that listing your bucket names (ListAllMyBuckets) is always permitted, so bucket scoping restricts access to bucket contents rather than hiding that other buckets exist.

This is useful when:

• Different services need access to different buckets
• You want to limit the blast radius of a compromised key
• External vendors or partners need access to a specific dataset

Key expiration

You can set an expiration date when creating a key. After the expiration date, the key no longer authenticates and requests signed with it fail with a 403 (typically AccessDenied or InvalidAccessKeyId).

Expiring keys are useful for:

• Temporary access grants
• CI/CD pipelines where you rotate credentials on a schedule
• Short-lived integrations

Viewing and managing keys

Go to API Keys in the left menu to see your keys. The list shows:

Column	Description
Name	The label you gave the key at creation, with the Access Key ID shown beneath it
Region	The region the key belongs to (hidden on narrow screens)
Buckets	Which buckets the key can access (all, or a specific set)
Permissions	The permissions granted to the key
Created by	Who created the key, and who rotated it and when. Shown when your organization has more than one member
Status	Currently always Active
Last Used	Currently always Never

Status and Last Used are placeholders for now, and the list doesn't show a key's expiry date, so keep your own record of when each key expires. You cannot view the Secret Access Key after creation.

Rotating a key

Rotation gives a key a new Access Key ID and Secret Access Key and keeps everything else: its name, permissions, bucket scope, region, and expiry date.

1. Find the key in API Keys, open its ⋯ action menu, and choose Rotate.
2. Confirm with Rotate key in the Rotate access key dialog.
3. Copy or download the new credentials from the Save your credentials dialog. As at creation, the secret is shown only once.

The old secret stops working as soon as the new one is issued, so update your applications right away. If the old key couldn't be revoked, the console tells you it is still active; delete it from the list yourself.

You can't rotate an expired key; create a new one instead. Rotate only appears on keys your current role could still create.

To move an application onto a key with different permissions or buckets, create the new key, switch the application over, then delete the old key.

Revoking a key

Find the key in API Keys, open its ⋯ action menu, and choose Delete. Deletion is forwarded to the regional storage operator; the key stops working once that change propagates, so treat revocation as taking effect quickly rather than at a guaranteed instant, and rotate anything that depended on it.

Security best practices

• Use separate keys per environment. Create different keys for development, staging, and production. This limits the impact if a key is leaked.
• Use the minimum permissions required. A key that only needs to read objects should not have Write or Delete permissions.
• Scope keys to specific buckets when possible, especially for external integrations.
• Set expiration dates on keys that are only needed temporarily.
• Rotate keys periodically. Use Rotate on the key, then update your application with the new credentials. See Rotating a key.
• Revoke keys immediately if you suspect compromise, and rotate anything that depended on them. Revocation is forwarded to the storage operator, so treat it as effective quickly rather than assuming a precise cut-off instant.
• Never hardcode credentials in source code. Use environment variables or a secrets manager.

See Authentication for how to configure your S3 client with your API keys.