Errors
Standard error response for all requests.
Don't you just hate when APIs have varying error response bodies for different endpoints and error codes? Maybe that's just a me thing.
Either way, TIKI uses the same HTTP error response body everywhere EXCEPT for OAuth. OAuth as a standard has it's own quirks and very a specific error response body format and codes. We elected to follow these, so our auth layer plays nicely with any libraries you might using.
Other than Authorization our errors all fit the following format. Values are optional, providing additional, helpful context for developers (not users) in addition to the standard HTTP status codes/messages. We do not double-up; use the status code provided in your response object.
{
"id": "string",
"message": "string",
"detail": "string",
"help": "string",
"properties": {
"property": "string",
}
}
Field | Description |
---|---|
id | An additional identifier, for when standard status codes are not granular enough. |
message | A short description of the error. |
detail | An extended description, typically used to elaborate on why/what caused the error. |
help | Information on how to fix the error. |
properties | A key-value map of the values that that caused the error. |
Example
{
"id": "420",
"message": "Missing Lighter",
"detail": "A lighter is required for creating a flame",
"help": "Find a 7/11",
"properties": {
"lighter": "null"
}
}
Updated 8 months ago