Invalid Secret Value
URI: https://docs.ankatech.co/errors/invalid-secret-value
HTTP Status: 400 Bad Request
When you see this
A writable-secret platform setting was submitted with a value equal to the masking sentinel that reads return in place of a stored secret. Accepting it would seal the literal mask characters as the real secret, so the write is rejected before any seal and before any settings-change notification. The prior ciphertext is unchanged.
Common Causes
- A form was loaded with the masked read value and submitted without the field being re-typed.
- A client round-tripped a
GETresponse straight back into aPUTwithout replacing the masked member.
Response Example
{
"type": "https://docs.ankatech.co/errors/invalid-secret-value",
"title": "Invalid Secret Value",
"status": 400,
"detail": "The submitted secret value is the read mask and cannot be stored",
"instance": "/api/v3/admin/platform/settings/ankasecure.notification.email.sendgrid.api-key",
"timestamp": 1730000000,
"extensions": {
"requestId": "3ba9d5e8-72f1-4c06-8d94-1e5b07c2fa38"
}
}
Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.
How to Resolve
- Type or paste the real secret value into the field before submitting.
- If you did not intend to change the secret, do not submit the setting at all — the stored value is already in force and reads never return it.
- In a client, treat the masked read as a presence indicator only and never send it back as a write value.
For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.