I.e. for insufficient quota I’ve got following json
entity: {
"error": {
"message": "You exceeded your current quota, please check your plan and billing details.",
"type": "insufficient_quota",
"param": null,
"code": null
}
}
This error is covered under code 429 on the link you shared.
429 - You exceeded your current quota, please check your plan and billing details Cause: You have hit your maximum monthly spend (hard limit) which you can view in the account billing section. Solution:Apply for a quota increase.
The question is asking where to find a comprehensive list of all error types for a particular API or service. The provided example shows an error message with a specific error type of “insufficient_quota”. The “Error codes” page mentioned only contains HTTP status codes and Python library error types, which may not include a list of all possible error types for the API or service being used. The question is asking whether the “type” field is meaningful and if a list of its values can be found or if it is necessary to rely on HTTP status codes only.
I’m reviving this thread, because I think that it’s crucial to have more documentation for errors returned through JSON responses.
Some HTTP codes are bundled together for multiple errors, such as 429, which is both “Rate limit reached for requests” and “You exceeded your current quota”.
An end user should know that a rate limit has been reached, so they halt their requests for a bit, but they shouldn’t know whether or not the quota has been exceeded. That’s the dev’s problem.
Unless my googling skills are very out of touch, I was unable to find any information on these JSON error types. Any assistance from the OpenAI team would be highly appreciated (ideally, documentation additions).
You shouldn’t be reporting on either rate as a problem with what the user is doing. You should be managing what you send and your capability (tier) to service customers so you don’t get errors.
HTTP has a limited number of response status codes. You would not want to extend the protocol inappropriately in a proprietary fashion, for example returning a 418 just because it is convenient code you think you can use to communicate.
Maybe 402: “Pay up, this isn’t free” would be appropriate for a subcategory of errors.
Well, obviously you don’t want to extend the protocol, that would cause nothing but confusion. I do agree with the 402 sub-error. So, you know… nudges OpenAI engineers