When a Vendor API Breaks, the Project Shouldn't

Naif Amoodi — Thu, 07 May 2026 13:22:30 +0000

One thing I've seen more than once in integration work is this: the vendor API becomes the problem.

At the start, it always looks straightforward. There's an API, the docs exist, and the plan seems clear enough.

Then the real work starts.

A field comes back in a different format than expected. An endpoint works in one environment and then acts differently in another. Something that looked fine in testing starts failing once real data or real usage hits it. We have also had cases where the docs looked fine, but the actual response shape coming back from the API was not something we could safely trust.

Or the API works, but not well enough to build the rest of the project around it with any confidence.

That is usually the point where you have to make a choice.

You can wait for the vendor to sort it out, which usually means your timeline starts depending on theirs.

Or you can accept that the API is not stable enough and design around that.

Most of the time, I would rather do the second.

If an API is shaky, I do not want the rest of the system tightly tied to it. I would rather isolate it and reduce the damage. Sometimes that means putting a small layer in front of it. Sometimes it means normalizing the response before the rest of the system touches it. Sometimes it means retries, queues, or some temporary workaround so one bad dependency does not slow everything else down.

Nothing fancy. Just enough to stop one unreliable piece from controlling the whole project.

I think this is where a lot of teams lose time. Everyone keeps waiting for the vendor's "real fix," even when it is obvious that waiting is just blocking the rest of the work.

I would rather keep things moving and clean it up later if the vendor side improves.

For me, the point is simple: if a vendor API breaks, the project should not break with it.

What an Old Oracle Database Taught Me About Not Trusting Assumptions

Naif Amoodi — Thu, 23 Apr 2026 09:27:57 +0000

We still work with a client whose entire operation revolves around an old Oracle database, so a lot of our work ends up depending on how that database behaves.

And honestly, that is where a lot of the pain starts.

One thing I have run into there is that not every table has a clean single primary key. In some cases, a row is really identified by a combination of several columns. That is manageable, but it becomes a headache when you are syncing data, updating records, or trying to explain row identity to another system that expects something simpler.

Another issue is that the database is old enough that I have learned not to assume consistency unless I have verified it myself.

A good example is dates. We ran into cases where a date would come back in one format from the CLI, but in a different format when the same data was accessed through an API layer. That is the kind of thing that can quietly create bugs if you trust the first result you see and move on.

This is why I try to be careful with old systems. The problem is not always that they are broken. Sometimes the problem is that they behave just differently enough in different environments to cause trouble later.

So my approach is usually to normalize early, validate what I can, and avoid building logic on top of assumptions that came from one test in one environment.

My main takeaway is simple: when your work depends on an old database, do not trust anything important until you have seen how it behaves in the real flow.

DEV Community: Naif Amoodi

When a Vendor API Breaks, the Project Shouldn't

What an Old Oracle Database Taught Me About Not Trusting Assumptions