Almost five years ago I wrote a post (in Italian) about what I jokingly called curlese: the practice of using curl as a universal language when an HTTP integration breaks and you need to figure out whose fault it is. The idea was simple: instead of arguing with a provider over log files they don’t want to read, you send them a curl command. It’s self-describing, it’s reproducible, and — crucially — it’s not your code, so nobody can dismiss it as “your application is buggy”.
Five years later, I can confirm the thesis held up embarrassingly well. I still do this constantly. But the world around the thesis changed quite a bit, so it’s time for an update: what changed, what didn’t, and what my survival kit looks like in 2026.
What didn’t change #
The social problem is exactly where I left it. Every integration still involves at least two teams, one firewall nobody fully understands, and a conversation that starts with “works on my side”. Your perfectly clear application logs are still worthless in that conversation, because:
the other side can’t (or won’t) interpret your logs
it’s always easier to assume the problem is you
you’re rarely talking to the person who can actually fix it
A curl command with its output solves all three. It’s executable evidence. You can paste it in a ticket, the other team’s network admin can run it as-is, and the verdict is written in plain text. This part of the post needs no update at all, which is either reassuring or depressing depending on your mood.
What changed #
Quite a lot, actually.
... continue reading