Skip to main content
When a Noteboxd API call fails, the response body contains a structured error object with a machine-readable code and a human-readable message. Use the code field in your application logic to branch on specific failure conditions — don’t rely on the message string, as it may change. The optional details field provides additional context when available.

Error response format

Every failed request returns a consistent JSON envelope:

Error code reference

4xx errors are not retryable without first fixing the underlying issue. Only 429 RATE_LIMIT_EXCEEDED and 500 INTERNAL_ERROR responses should be retried — and only after addressing the root cause or waiting for the rate-limit window to reset.

Handling errors in code

The example below shows a practical pattern for catching and branching on Noteboxd error codes in JavaScript:
The X-RateLimit-Reset response header contains a Unix timestamp indicating when your daily quota resets. Read this value before scheduling a retry so you don’t waste calls.

Retrying on 500 errors

INTERNAL_ERROR responses indicate an unexpected problem on Noteboxd’s servers. When you encounter one, retry the request using exponential backoff — for example, wait 1 second before the first retry, 2 seconds before the second, 4 seconds before the third, and so on.
If INTERNAL_ERROR responses persist after several retries, please contact the Noteboxd developer support team at https://developers.noteboxd.com with the request details and any error details from the response body.
Noteboxd does not bill you for failed requests. You will not be charged for calls that return a 4xx or 5xx response.