Rename an API key or change its origins
const url = 'https://api.pixonaut.app/v1/api-keys/example';const options = { method: 'PATCH', headers: {Authorization: 'Bearer <token>', 'Content-Type': 'application/json'}, body: '{"allowedOrigins":["https://shop.acme.example","https://eu.acme.example"],"label":"Storefront widget (EU)"}'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request PATCH \ --url https://api.pixonaut.app/v1/api-keys/example \ --header 'Authorization: Bearer <token>' \ --header 'Content-Type: application/json' \ --data '{ "allowedOrigins": [ "https://shop.acme.example", "https://eu.acme.example" ], "label": "Storefront widget (EU)" }'Operation ID: apiKeys.update
Takes what creating that kind of key takes: a secret or integration key, api-keys:manage; an MCP key, being the member who created it. A key from the deployment’s configuration (managed) is not changed here, nor a key a connected store was given, except to rename its integration key: a store’s site is changed by connecting it again. Later audit entries name a renamed key by its new name; earlier ones keep the name it had when it acted.
Authorizations
Section titled “Authorizations”Parameters
Section titled “Parameters”Path Parameters
Section titled “Path Parameters”Request Bodyrequired
Section titled “Request Bodyrequired”object
A publishable key’s origins, replacing the ones it has. Refused for any other kind.
The key’s new name.
Examples
Example
{ "allowedOrigins": [ "https://shop.acme.example", "https://eu.acme.example" ], "label": "Storefront widget (EU)"}Responses
Section titled “Responses”The key, changed
object
Examples
Example
{ "allowedOrigins": [ "https://shop.acme.example", "https://eu.acme.example" ], "id": "0b1c2d3e-4f50-4a6b-8c7d-000000000006", "kind": "pk", "label": "Storefront widget (EU)"}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Refused: invalid_origin, origins_not_allowed, invalid_input
object
Always sent with invalid_origin.
Examples
invalid_input
{ "error": "invalid_input"}invalid_origin
{ "error": "invalid_origin", "origin": "string"}origins_not_allowed
{ "error": "origins_not_allowed"}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Refused: unauthorized
object
Examples
unauthorized
{ "error": "unauthorized"}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Refused: forbidden, feature_disabled, origin_forbidden
object
The feature the tenant does not have. Always sent with feature_disabled.
Examples
feature_disabled
{ "error": "feature_disabled", "feature": "api"}forbidden
{ "error": "forbidden"}origin_forbidden
{ "error": "origin_forbidden"}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Refused: not_found
object
Examples
not_found
{ "error": "not_found"}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Refused: config_managed, connection_key
object
Examples
config_managed
{ "error": "config_managed"}connection_key
{ "error": "connection_key"}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Refused: payload_too_large
object
Always sent with payload_too_large.
Examples
payload_too_large
{ "error": "payload_too_large", "maxBytes": 0}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Refused: db_error. A request that failed unexpectedly answers as text instead.
object
Examples
db_error
{ "error": "db_error"}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Questions? Write to [email protected].