> ## Documentation Index
> Fetch the complete documentation index at: https://www.edenai.co/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Post managekeys rotate

> ``POST /v3/manage/keys/{key_id}/rotate`` (manage:write) -- replace a key's secret in place: same
identity (name, key_id, budget, guardrail), a brand-new ``sk-eden`` value returned ONCE. Lets a
compliance pipeline roll a secret without reconfiguring the key. Distinct from DELETE: revoke KILLS
(terminal), rotate RE-SECRETS.

A REVOKED key is a 404 here, never resurrected. ``rotate_key_secret`` clears ``revoked_at`` and
writes fresh secret material, so rotating a revoked key would REVIVE it -- the exact one-way-door
that revoke depends on. The read filters a revoked (or cross-org, or unknown) key_id to a 404, and
the whole rotate runs in a transaction that ``select_for_update``-locks the row: a concurrent DELETE
either commits its revoke first (``revoked_at`` then filters the row out -> 404) or blocks on the
lock until the rotate commits and then still wins its own compare-and-set. Without the lock the read
filter alone is a check-then-act race -- a rotate that resolved a live key could blind-write a fresh
secret AFTER a concurrent revoke landed, resurrecting a terminally-revoked key. So revocation stays
terminal.



## OpenAPI

````yaml https://api.edenai.run/v2/info/splitted-schema/management_api/openapi.json post /manage/keys/{key_id}/rotate/
openapi: 3.0.3
info:
  title: Organization Management
  version: '2.0'
  description: Your project description
servers:
  - url: https://api.edenai.run/v3
security: []
paths:
  /manage/keys/{key_id}/rotate/:
    post:
      tags:
        - keys
      description: >-
        ``POST /v3/manage/keys/{key_id}/rotate`` (manage:write) -- replace a
        key's secret in place: same

        identity (name, key_id, budget, guardrail), a brand-new ``sk-eden``
        value returned ONCE. Lets a

        compliance pipeline roll a secret without reconfiguring the key.
        Distinct from DELETE: revoke KILLS

        (terminal), rotate RE-SECRETS.


        A REVOKED key is a 404 here, never resurrected. ``rotate_key_secret``
        clears ``revoked_at`` and

        writes fresh secret material, so rotating a revoked key would REVIVE it
        -- the exact one-way-door

        that revoke depends on. The read filters a revoked (or cross-org, or
        unknown) key_id to a 404, and

        the whole rotate runs in a transaction that ``select_for_update``-locks
        the row: a concurrent DELETE

        either commits its revoke first (``revoked_at`` then filters the row out
        -> 404) or blocks on the

        lock until the rotate commits and then still wins its own
        compare-and-set. Without the lock the read

        filter alone is a check-then-act race -- a rotate that resolved a live
        key could blind-write a fresh

        secret AFTER a concurrent revoke landed, resurrecting a
        terminally-revoked key. So revocation stays

        terminal.
      operationId: manage_keys_rotate_create
      parameters:
        - in: path
          name: key_id
          schema:
            type: string
            format: uuid
          required: true
      responses:
        '200':
          description: No response body

````