Skip to main content
The Zeeg API uses standard HTTP status codes to indicate the success or failure of a request. Codes in the 2xx range indicate success, 4xx codes indicate a client error, and 5xx codes indicate a server-side issue.

​
Status codes

CodeMeaningDescription
201CreatedThe resource was created successfully.
400Bad RequestThe request is malformed or contains invalid parameters.
401UnauthorizedAuthentication is missing or invalid.
403ForbiddenYou do not have permission to access the resource.
404Not FoundThe requested resource does not exist.
409ConflictThe resource already exists or conflicts with the current state.
422Unprocessable EntityThe request body failed validation.
429Too Many RequestsYou have exceeded the rate limit. See Rate Limits.
500Internal Server ErrorSomething went wrong on our end.

​
Error response shapes

The exact response shape varies slightly between endpoints. Some endpoints use an error field, while others use a success + message pattern. Always check the HTTP status code first, then parse the response body.
Returned when the request is malformed or a required parameter is missing.
{
  "success": false,
  "message": "Missing required parameter: event_uuid.",
  "status": 400
}
​
success
boolean
Always false for error responses.
​
message
string
A human-readable description of the error.
​
status
integer
The HTTP status code.

​
Best practices

  • Check the HTTP status code first. The status code is the most reliable indicator of what happened. Parse the response body only after determining the status.
  • Handle both error shapes. Some endpoints return {"error": "..."} while others return {"success": false, "message": "...", "status": ...}. Your client code should handle both.
  • Use 422 errors for form validation. The errors object gives you per-field messages you can surface directly to users.
  • Retry on 500 errors. Internal server errors are transient. Use exponential backoff when retrying.
Last modified on April 4, 2026