Update a CometAPI key by its JSON-body ID

General
1

For a CometAPI API-key update, put the numeric key ID in the JSON body—not at the end of the URL. The documented request shape is:

PUT /api/token/
Content-Type: application/json

The identity portion of the body looks like this, using a made-up ID:

{
  "id": 1234
}

This is an identity fragment, not a complete update payload. CometAPI’s Update an API key documentation says id is required and comes from the List API keys operation. For updates, the documentation explicitly says to send that value in the body, not in the URL.

Build the update deliberately

For a management client, I would separate request construction into three steps:

  1. Identify the intended key using the numeric ID returned by List API keys.
  2. Keep the update route as PUT /api/token/ and include that ID as the body’s integer id field. Do not construct PUT /api/token/1234 from the illustrative value above.
  3. Add the editable fields you intend to change and the editable values you need to preserve, based on the current key record and the documented request fields.

The third step matters: the same CometAPI page warns that omitted numeric, boolean, or string fields can be reset. Do not treat the small identity fragment above as a safe partial update. My recommendation is to compare the intended outgoing editable fields with the current record before sending anything, rather than relying on omission to mean “leave unchanged.”

The narrow takeaway is an addressing rule: the route chooses the update operation; the JSON id chooses the key. This explanation follows the official documentation captured on September 5, 2026; it does not report a live API test or a successful update. Consult the linked page for authorization requirements and the full field contract before making a request.

2

One implementation detail worth making explicit is how a client should guard this distinction before it reaches the transport layer. Treat the key ID as a typed field in the update request model, then serialize it into the JSON object for PUT /api/token/; do not let a generic URL builder turn every resource identifier into a path segment.

A useful preflight is to display a redacted request shape such as { "id": 1234, ...editable_fields } and compare the outgoing editable fields with the record returned by List API keys. That catches both the path/body mix-up and accidental omission of fields that the documentation says may reset. It also keeps the illustrative numeric ID separate from the ID selected for a real request.

This is a client-side correctness check, not evidence that the endpoint was exercised successfully; the full field contract and authorization requirements still need to come from the official documentation.