mirror of https://github.com/zulip/zulip.git
51 lines
1.7 KiB
Markdown
51 lines
1.7 KiB
Markdown
# Error handling
|
|
|
|
Zulip's API will always return a JSON format response.
|
|
The HTTP status code indicates whether the request was successful
|
|
(200 = success, 40x = user error, 50x = server error). Every response
|
|
will contain at least two keys: `msg` (a human-readable error message)
|
|
and `result`, which will be either `error` or `success` (this is
|
|
redundant with the HTTP status code, but is convenient when printing
|
|
responses while debugging).
|
|
|
|
For some common errors, Zulip provides a `code` attribute. Where
|
|
present, clients should check `code`, rather than `msg`, when looking
|
|
for specific error conditions, since the `msg` strings are
|
|
internationalized (e.g. the server will send the error message
|
|
translated into French if the user has a French locale).
|
|
|
|
Each endpoint documents its own unique errors; below, we document
|
|
errors common to many endpoints:
|
|
|
|
## Invalid API key
|
|
|
|
A typical failed JSON response for when the API key is invalid:
|
|
|
|
{generate_code_example|/rest-error-handling:post|fixture(400_0)}
|
|
|
|
## Missing request parameter(s)
|
|
|
|
A typical failed JSON response for when a required request parameter
|
|
is not supplied:
|
|
|
|
{generate_code_example|/rest-error-handling:post|fixture(400_1)}
|
|
|
|
## User not authorized for query
|
|
|
|
A typical failed JSON response for when the user is not authorized
|
|
for a query:
|
|
|
|
{generate_code_example|/rest-error-handling:post|fixture(400_2)}
|
|
|
|
## User account deactivated
|
|
|
|
A typical failed json response for when user's account is deactivated:
|
|
|
|
{generate_code_example|/rest-error-handling:post|fixture(403_0)}
|
|
|
|
## Realm deactivated
|
|
|
|
A typical failed json response for when user's organization is deactivated:
|
|
|
|
{generate_code_example|/rest-error-handling:post|fixture(403_1)}
|