Salesforce ships three releases a year. SAP ships Enhancement Packages and Support Packs on a published schedule. Workday, NetSuite, and Dynamics 365 all publish release notes months ahead of time. Enterprise IT teams have gotten reasonably good at bracing for these changes, because there is a calendar to watch and a changelog to read before anything ships.

The harder problem sits with the APIs that do not work that way. Smaller SaaS vendors, internal microservices, and plenty of tools your company depends on every day ship changes continuously and never attach a version number to any of it. No changelog. No deprecation notice. No four-month warning window. Just a payload that looks a little different than it did yesterday.

The Versioning Assumption Built Into Most Monitoring

Most schema drift tooling quietly assumes there is a before and an after to compare. Tools like openapi-diff and oasdiff compare two versions of an OpenAPI spec and tell you exactly what changed between them. Contract testing frameworks like Pact validate a consumer's expectations against a specific provider version. Even reactive monitoring often keys off a version header or a release tag to know when to re-baseline.

That assumption works fine for vendors who version deliberately. Stripe is the textbook example: every account is pinned to a dated API version string, and Stripe will not change response behavior for your integration until you explicitly upgrade. It is a deliberate, well-documented discipline, and it is the exception rather than the rule.

Why So Many Vendor APIs Skip Versioning Entirely

Versioning an API properly is expensive. It means maintaining multiple response shapes in parallel, documenting deprecation timelines, and giving customers a migration window before old code paths can be deleted. A lot of vendors, especially smaller ones running continuous deployment, do not have the engineering headcount or the incentive to do that work.

So instead, changes ship as "improvements." A field that used to return null now gets omitted from the payload entirely. A status enum gains a new value nobody told you about. A webhook payload gets an extra nested object because a product team needed it for their own dashboard. None of this shows up as a version bump, because there is no version to bump. From the vendor's side, it is a minor internal change. From yours, it is an undocumented breaking change with no advance notice.

What Actually Breaks When There Is Nothing to Diff

The failure patterns are familiar even when the cause is not:

A new enum value hits a switch statement with no default case, and the record silently falls through to whatever the fallback branch does.
A field that used to be present with a null value gets omitted from the JSON entirely, and a strict deserializer treats "missing" differently than "null."
Pagination cursor format changes from an offset integer to an opaque token, and your loop either breaks loudly or, worse, quietly stops after page one.
Timestamp precision shifts from seconds to milliseconds without documentation, and every downstream calculation that assumes seconds is off by three orders of magnitude.
A field gets renamed in a routine update that also touched the underlying API response, and your mapping keeps working because it defaults to null instead of throwing an error.

The Detection Gap Is Semantic, Not Just Structural

Some of these are structural drift, and a decent JSON schema validator will catch them if you have one wired in. The more dangerous cases are semantic. The shape of the payload does not change at all. A currency field that used to represent a listed price starts representing a price after a regional discount. A boolean flag that meant "eligible" now means "eligible and verified." Nothing about the schema tells you this happened. The field name, type, and structure are all identical. The meaning underneath has shifted.

This is the same category of problem as schema drift more broadly, but the unversioned case is worse because there is no changelog to search for a clue. You cannot go read the release notes for a change that was never announced as a release.

A Practical Approach: Baseline the Behavior, Not the Version

If you cannot diff against a published spec, the alternative is to diff against reality. This means capturing a baseline of what a vendor's live responses actually look like, structurally and statistically, and continuously comparing new traffic against that baseline rather than against a document. Field presence rates, value distributions, enum cardinality, and null rates are all measurable without any cooperation from the vendor.

A few practices make this workable in production:

Log a sample of raw responses over time so you have a historical baseline to compare against, not just the most recent call.
Track field-level statistics like null rate and cardinality, not just presence or absence, since a field that starts returning null 40 percent of the time is a signal even if it never disappears.
Treat webhook payloads as a public contract even when the vendor does not document them that way, since webhooks are frequently the least stable part of an integration.
Set alerts on distribution shifts, not just structural changes, so semantic drift with an unchanged schema still gets flagged.

What This Means for Your Monitoring Stack

The practical takeaway is that monitoring built around version diffing will always have a blind spot sized exactly to the number of vendors who do not version their APIs, which in most enterprise stacks is a meaningful chunk of the integration estate. The fix is not asking every vendor to adopt semantic versioning. That is not going to happen. The fix is building detection that does not need a version number to work in the first place, one that watches actual behavior and flags drift the moment it happens rather than the moment someone reads a changelog that was never written.

mmune's semantic watchdogs work exactly this way. They build a baseline from your live data flows, not from a vendor's documentation, so a field rename, a value range shift, or a quietly added enum value gets caught whether or not anyone bothered to publish a release note about it. If part of your integration estate depends on vendors who ship changes with no warning, that is worth finding out before it costs you three weeks of bad data. Find your blind spots.

When Your Vendor's API Has No Version Number, You're the Only Safety Net