Customer Saw Another's Data in Your API? Oat Milk Queue

2026-10-30

The message arrives at 8:41 on a Wednesday, while you are third in the queue at the market coffee stall.

You are holding a reusable cup and your phone. The subject line says: Is this supposed to happen?

It is from a customer of the small booking tool you built last spring. She runs a dog-grooming studio. Under her message is a screenshot. It shows a list of appointments, and the names are not hers.

The barista asks what you'd like. You say oat flat white. You don't hear yourself say it.

The sentence you read twice

She writes that she was changing a number in the address bar, out of curiosity, because she'd noticed the page had a number in it. Then the page showed someone else's calendar. First names, phone numbers, a note that says nervous around clippers.

She isn't angry. She is polite, and that makes it worse. She says she thought you would want to know.

You stand by the milk station and your thoughts run in the wrong order. Which endpoint? Since when? How many people could have done this? Did I test that? I tested it. Didn't I?

You did test it. You tested that logging in worked. You tested that a wrong password failed. You tested that the app showed the right calendar to the right person, because you were always logged in as the right person.

Nobody had ever asked the question she accidentally asked: what if I'm logged in, but I ask for someone else's thing?

The walk back to the desk

The coffee goes cold on the way home. You don't notice.

At your desk, the logs come first. They say what they say. It is less dramatic than your stomach predicted and also more specific. You find the route. You find the single missing check, one that decides whether the thing being asked for belongs to the person asking.

The fix takes a few minutes. You deploy it. You check it three times, because the first two don't feel like enough.

Then comes the part nobody warns you about: the quiet after the fix. The code is right and you still feel wrong. The question that lingers isn't how do I fix it? It's how did I miss this, and what else did I miss?

That second question has no bottom. You can feel yourself opening other files, looking for the next one by hand, in a mood that isn't careful. It's frantic. Frantic reading finds some things and skips others.

What the customer deserves, and what you deserve

You write back to her before lunch. Plain words, no drama: what happened, that it is fixed, that you are looking at what else could be affected, and that you will tell her what you find. You thank her, and you mean it.

Then you do the honest thing and look at your own process rather than your own character.

You didn't miss this because you are careless. You missed it because your review lived in your head. It was a loose sense of I think I covered the usual things, assembled from whatever you remembered that week. A head does not hold a list. A head holds the parts that scared you last time.

The parts that scared you were passwords and tokens. The part that bit you was ordinary and quiet: a correct login asking for the wrong record.

There is a small relief in seeing that. The gap wasn't a flaw in you. It was a gap in having a written order of things to check, one that is the same every time and doesn't depend on how your week went.

The Wednesday that could have been different

Imagine the same morning, a few months from now.

You are in the same queue. The same kind of message might arrive, because customers are curious and the internet is large. But before you launched the last feature, you sat down with a list. It was not a long, scary one. It was a calm, numbered thing you worked through once, ticking items off, with the awkward questions already written down so you didn't have to invent them under pressure.

If a message came now, you would still feel your stomach move. But the next thought would be different. Not did I test that? but I know what I checked, and I know where I wrote it down.

That is the whole difference. Not perfection, which nobody can promise. Just a record you can open when someone asks, whether it's a customer, a boss, or you at 3 a.m. wondering.

It also means that when a client asks, "Is our data safe with you?", you can answer with something other than a hopeful nod.

A gentler way to launch

You eventually go back for a fresh coffee. It's lukewarm by the time you've paid, but you drink it standing at the window, and your shoulders come down a little.

The customer writes back mid-afternoon. She says thanks for the quick answer, and that she's heading to a groomer's appointment of her own, with a very small, very loud terrier. You laugh, which you did not expect to do today.

Nothing about this day will end up in a highlight reel. But you decide that the next time, the checking won't wait for someone else's curiosity.

If you recognise yourself in this scene, there is a kit built for exactly that gap. It is a 58-item REST API security review: a PDF checklist and a tracker spreadsheet, plus curl tests, a script that scans for auth-route gaps, and a client report template, for Node/Express and Python. It was made with AI, checked automatically and refined by real use. It supports your review. It does not replace a professional security audit when you need one. If it doesn't help, the 30-day money-back promise applies, no questions.

Launch Without the 2 a.m. Doubt – REST API Security Checklist Kit

An illustrative story, written with AI assistance.