BackendLesson 2 of 48 min
Reading errors instead of fearing them
Status codes tell you whose fault it is. That is most of debugging an integration.
Every response carries a three digit status code, and the first digit is the only part you need to memorise. It tells you which side to go and look at.
- 2xx
It worked. 200 fine, 201 created something. - 3xx
It moved. Look somewhere else. - 4xx
You asked wrong. Your fault, so fix the request. - 5xx
They broke. Their fault, so retrying might work.
- 400: the request itself is malformed.
- 401: I do not know who you are. Log in.
- 403: I know who you are and you are not allowed. Logging in again will not help.
- 404: no such thing here.
- 429: you are asking too often. Slow down.
- 500: something on our end broke and we did not handle it.
When something goes wrong with an API, the first three things to look at are always the same: the status code, the response body, and whether the request you sent was the request you thought you sent. That last one is a browser network tab away and is the answer more often than anyone admits.
What to remember
- 4xx is your fault, 5xx is theirs. Retry only the second kind.
- 401 means unidentified, 403 means unauthorised. They need different responses.
- Check what you actually sent before blaming what came back.
Terms in this lesson
Show field notes toggles a search param the loader reads. With it off, the slow promise is never created, so nothing streams.