---
title: "Rotate the metadata token"
method: POST
path: "/storage/cloudfs/{id}/actions/rotate-meta-token"
tags: ["cloudfs filesystems"]
---

# Rotate the metadata token

`POST /storage/cloudfs/{id}/actions/rotate-meta-token`

Issues a new metadata access token for the filesystem and returns the full filesystem, including the new `meta_token` and credential-bearing `meta_url`. The previous token stops authenticating immediately; the metadata database and S3 bucket are unchanged. The request takes no body. Allowed while the filesystem is `ready` or `needs_format`; otherwise returns a `409`. Retrying with the same `Idempotency-Key` within 24 hours replays the original response — including the same token — instead of rotating again.

## Path parameters

- `id` string, uuid, required

## Headers

- `Idempotency-Key` string, required

## Response `200`

New metadata token issued; the response includes the new `meta_token` and credential-bearing `meta_url`

- CloudfsFilesystemResponseWrapper
  - `data` CloudfsFilesystem — A CloudFS filesystem, including its metadata credential. This shape is returned only by create and rotate-meta-token.
    - `record_type` string
    - `id` string, uuid
    - `name` string
    - `status` 'provisioning' | 'ready' | 'needs_format' | 'deleting' | 'failed' | 'deleted' — Lifecycle status of the filesystem. `ready` means it is fully provisioned and usable. `needs_format` means the storage bucket and metadata database were provisioned but the filesystem has not yet been formatted — run `juicefs format` with the filesystem's `meta_url` before mounting. `failed` means the last lifecycle action failed — see the filesystem's `error` message. `deleted` appears only in the delete response: deleted filesystems are excluded from list results and return a `404` on retrieval.
    - `meta_url` string — PostgreSQL connection URL for the filesystem's metadata database. In create and rotate-meta-token responses it embeds the metadata token as the password: `postgres://<database>:<meta_token>@us-east-1.telnyxcloudfs.com:5432/<database>?sslmode=require` (the example below is shown without the credential; the actual response includes it). Pass it to `juicefs mount`: the storage configuration is baked in at provisioning, so the metadata URL is all a client needs to mount the filesystem.
    - `meta_token` string — Metadata access token, in cleartext. Returned only by create and rotate-meta-token and not retrievable afterwards — store it securely.
    - `s3_endpoint` string — URL of the Telnyx Cloud Storage endpoint backing this filesystem.
    - `s3_bucket` string — Name of the bucket that stores this filesystem's data. Created during provisioning.
    - `region` string
    - `created_at` string, date-time
    - `updated_at` string, date-time

## Other responses

- `400` — Bad request — missing or invalid `Idempotency-Key` header
- `401` — Unauthorized
- `404` — CloudFS filesystem not found
- `409` — Conflict — the filesystem is not in a state that allows rotation (`status` is neither `ready` nor `needs_format`), or a request with this `Idempotency-Key` is still being processed
- `422` — Unprocessable entity — `id` is not a valid UUID, or the `Idempotency-Key` was already used for a different request
- `500` — Internal server error

---

[API](https://skmtc.net/team-telnyx/apis/telnyx-api-2.md) · [All operations](https://skmtc.net/team-telnyx/apis/telnyx-api-2/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/team-telnyx/telnyx-api-2/versions/8f5f4e537994/schema)