2

Each user has daily credit limit.

If user exceeds their daily limit what HTTP status code would be right here.

403 -Forbidden or 200 -Success (with validation Result)

Charlieface
  • 52,284
  • 6
  • 19
  • 43
sekar perumal
  • 41
  • 3
  • 403 kind of gets the point across. Or just generic 400. 429 might be just what you want though https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429 – Valuator Mar 29 '23 at 15:23
  • If the user has a credit balance and needs to top up then 402 might make more sense https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402 – Charlieface Mar 29 '23 at 15:34
  • Note that the response body may contain a message related to the error reason. – Graffito Mar 29 '23 at 15:34

1 Answers1

5

Neither. You're describing rate limiting. There is a definite status code for this: 429.

403 is about security, particularly, authorization... whether you are authorized to do something without regards to how often. 403 is orthogonal to rate limitations. Think of it this way: if I ask to "add item to cart", with 403 I know I can't regardless of if it's my first ask or my Nth ask in some period of time. Done. With 429 I know I can (403 didn't happen or doesn't apply), but I also now know I'm trying to do it too quickly for whatever reason.

200 is also not appropriate: naive clients just assume all is OK, ignore any additional detail, and silently fail the user with a false sense that all is OK when really what happened is the server wants to say, "no way can I deal with this now".

A 429 is enough by itself, but smart clients would also look for the Rety-After header, which a well-designed API (and API client) should implement to reduce the load on both the server and client (cooperative).

Presumably, if you know how the rate limit was just "violated" you can calculate a value for Retry-After that can be fairly precise. You can take a look at the formats in the Mozilla docs for Retry-After, which can be in seconds or a specific date/time. I've done this before and added a "fudge factor" to avoid unnecessary new requests too soon.

While rate limiting with this method could be abused by bad actors, it at least helps in the nominal rate limiting scenarios for both your server and the client to reduce network (and other) resource utilization.

Finally, in the end 429 is right for your scenario, but the other statuses do need to be considered. The order of a call (I'm including the whole chain to the API including proxies) returning 400, 429, 403 before 200 can vary depending on which of the 4xx errors are handled by API and proxies. Ideally the least expensive 4xx check happens first (closer to the client).

Kit
  • 20,354
  • 4
  • 60
  • 103