Working with APIs is not just about exchanging data but also about communication. You send a request, you wait, you get a response. And depending on what that response contains (a success status, an error code, a timeout, or unexpected data), you make a decision. Retry? Modify the payload? Or give up?

It’s funny how similar this is to our real-life interactions with people.

In life, we’re constantly sending out “requests”: sharing a thought, expressing a feeling, offering help, asking for clarity, setting a boundary. But the real art isn’t just in the sending. It’s in how well we observe and interpret the response.

Did they get it?
Are they responsive or evasive?
Was there a miscommunication (like a 400 Bad Request)?
Are they overwhelmed or shut down (like a 429 Too Many Requests)?
Or are they giving you an error that’s actually about their internal system, not you?

[E.g.: Some people will give you a 401 Unauthorized response to your boundary, and you’re like, I literally just asked for basic respect, what kind of API key do I need for that?]

And just like with APIs, you can’t keep resending the same request and hope for a different response. Sometimes, you need to refactor your payload, or change the timing to retrigger it another time – but if you make those changes without accurate evaluation of the response, it may never land the way you hoped.

At some point you realise that if you’re constantly having to reformat your requests to get a decent response, and if the API still keeps failing, maybe it’s not your code. Maybe you’re sending requests to the wrong server. Like when the response is crystal clear (403 Forbidden), the wisest thing you can do is stop trying and move on.

But we’re not always the ones sending requests. Sometimes, we’re on the other end. Someone reaches out – maybe with a feeling, an assumption, or an unspoken expectation. And we’re about to send a response. That response might be warm and receptive 200 OK – or it might be guarded, hesitant, or just an error.

Maybe we delay replying because we’re processing. Maybe we snap back with a 500 Internal Server Error because their request was incompatible with our system.

Our responses, too, carry meaning. They teach others how to engage with us – what we’re open to, what needs a retry with better headers, and what boundaries are non-negotiable.

The best developers know when to troubleshoot and when to accept the limits of an API. The same goes for people: not all connections are good for integration, and not all errors are worth decoding.

But it’s always worth really reading the responses before sending the next request, just in case both systems can build compatibility after all.