Errors & Status Code

Applications integrating with external APIs must be prepared for validation errors, authorization failures, network problems, and temporary service interruptions.

This guide explains common HTTP error-handling principles.

HTTP status codes

Status	Meaning	Recommended action
200	OK	Process the successful response
201	Created	Handle the newly created resource
202	Accepted	Check the documented operation lifecycle
204	No Content	Do not expect a response body
400	Bad Request	Review request structure and parameters
401	Unauthorized	Check authentication credentials
403	Forbidden	Check authorization and permissions
404	Not Found	Verify the requested resource
409	Conflict	Investigate the conflicting operation or resource state
422	Unprocessable Content	Review semantic validation requirements
429	Too Many Requests	Follow documented throttling and retry guidance
500	Internal Server Error	Investigate or retry only when safe
502	Bad Gateway	Treat as a possible upstream failure
503	Service Unavailable	Follow documented availability and retry guidance
504	Gateway Timeout	Determine whether the operation may have completed

These are standard HTTP interpretations. Specific Senmo endpoints may use only a subset.

Error response bodies

Some APIs provide structured error information.

An illustrative response might look like:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "The request contains invalid data."
  }
}

This is not a guaranteed Senmo error schema. Actual response fields are defined in the product API reference.

Network failures

A network timeout does not necessarily mean that the requested operation failed.

The server may have received and processed the request before the connection was interrupted.

For financial transactions, digital asset transfers, or voucher redemption, blindly repeating an operation can produce unintended duplicate effects.

Recommended error-handling approach

Capture the HTTP status and documented error details.
Distinguish validation failures from temporary infrastructure failures.
Record relevant request identifiers where available.
Avoid logging credentials or sensitive personal information.
Determine whether retrying is safe.
Reconcile uncertain operation outcomes before attempting another state-changing request.

Troubleshooting

When investigating an issue, record the affected platform, environment, operation, timestamp, and sanitized error response.

Consult the product-specific API reference for exact error codes and recovery procedures.