Overview

When you integrate with the Kamino APIs, don't assume that every API response returns a 2xx success status code. Like most modern APIs, Kamino APIs might return different HTTP status codes depending on request validity, authentication status, resource availability, or internal system state.

For this reason, your client integrations must properly handle, log, and monitor non-2xx responses. If you fail to manage these responses, it might result in silent failures, incomplete data processing, or a degraded user experience.

Best practices

Implement status code handling

Your integration should explicitly handle responses outside the 2xx range, and it should apply the appropriate logic depending on the returned code.

Examples include the following:

• Retry logic for temporary errors
• Authentication refresh for authorization failures
• Error logging and alerting

Monitor non-2xx responses

Implement monitoring and alerting for unexpected API responses is strongly recommended. Tracking error rates helps you quickly detect integration issues or service disruptions.

Examples of monitoring signals include:

• An increased rate of 5xx errors
• Repeated authentication failures
• Missing resources or invalid endpoints

Log API responses for troubleshooting

You should log API responses that have non-2xx status codes with sufficient context. This context includes:

• The request endpoint
• The request payload
• The response status code
• The error message (if provided)

This tracking simplifies troubleshooting and support investigations.

Common status codes

The following table provides examples of status codes that the APIs might return. This list isn't exhaustive.

Key takeaway

Client integrations shouldn't rely solely on successful responses. Proper handling, logging, and monitoring of non-2xx HTTP status codes are essential to build a robust and resilient integration with the Kamino APIs.