API Version Detection: a beginner's guide
Detect API versioning strategy
API versioning: how APIs change without breaking everyone
API versioning is the practice of explicitly labeling each release of a public API with a version identifier — `v1`, `v2`, `2024-01-15`, or something similar — so that clients can pin themselves to a specific version and not break when the API evolves. Without versioning, every change to the API is a potential breaking change for every client using it; with versioning, the API can introduce new features, deprecate old ones, and even ship completely new contracts in parallel with the old ones, giving clients time to migrate. Versioning is one of those things that is invisible until it isn't, and the choice of versioning strategy says a lot about how seriously the API team takes their integrators.
You should care because the API versioning strategy is one of the strongest signals of API maturity. A v1-only API that has been live for years and never bumped to v2 is either extraordinarily well-designed or has been frozen out of fear of breaking customers. An API that bumps version numbers every six months is a fast-moving but volatile target. An API with date-based versioning (`2024-01-15`) like Stripe's is doing serious deprecation work and deserves trust. An API with no version number anywhere is a red flag for any integrator — every change is a breaking change waiting to happen.
The four major versioning strategies every check distinguishes:
URL path versioning. `/v1/users`, `/v2/users`. The most common, easiest to read, hardest to deprecate gracefully.
Header versioning. A custom header like `Accept: application/vnd.example.v2+json` or `X-API-Version: 2024-01-15`. More flexible but harder for clients to discover.
Date-based versioning. Each release of the API is identified by a date. Pioneered by Stripe and now widely copied. Very deprecation-friendly.
No versioning. The API is whatever it is right now, and breaking changes can happen at any time. Common in internal APIs and bad public ones.
Three questions an API version check answers:
What versioning strategy does this API actually use?
For an integration project, which version should I pin against, and how long is it likely to be supported?
For a vendor evaluation, does this team take backward compatibility seriously enough to trust them with a long-term integration?
The cost of integrating with a poorly-versioned API is breaking on every release, scrambling to update client code, and never being able to confidently ship to production. The fix is to choose API providers whose versioning strategy matches your tolerance for change — and to know the strategy before you start the integration, not after.
The API Version Detection endpoint, in plain language
In one sentence: Detect API (Application Programming Interface) versioning strategy
Analyzes how an API (Application Programming Interface) implements versioning. Detects URL (web address) path versioning and header-based versioning, and discovers available API versions.
Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.
What is actually happening when you call it
Here's what's actually happening behind the scenes when you call this endpoint:
Tests common URL (web address) path versioning patterns (/v1/, /v2/, /API/v1/, /API/v2/) with parallel batch probing. Validates responses by checking Content-Type for JSON/XML to avoid SPA false positives. Identifies available API (Application Programming Interface) versions and the versioning strategy (URL path-based).
If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.
Why this specific tool matters
Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the API Version Detection tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.
Understanding API (Application Programming Interface) versioning helps with integration planning, security assessment (older versions may have vulnerabilities), and competitive analysis of API maturity.
Picture this in real life. Imagine a developer. Here's the situation they're walking into: Understand versioning strategy before integrating with an API (Application Programming Interface). Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the API Version Detection tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.
Three questions this tool answers in plain English. If any of these have ever crossed your mind, the API Version Detection tool is built for you:
What is this website actually built with, layer by layer?
Who hosts it, who runs analytics on it, who delivers the assets?
Is the company on a stack that fits my product, my pitch, or my integration?
You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.
Who gets the most out of this. Sales teams qualifying leads, marketers researching competitors, partnership managers scoping integrations, and security teams looking for known-vulnerable software in the wild. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.
What happens if you skip this entirely. Skip it and you're guessing at how a website is built — which kills sales calls, integration scoping, and competitive research. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.
Available on the developer plan. The technical details: `GET /v1/domain/api-version`.
When would I actually use this?
If you're still on the fence about whether the API Version Detection tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a developer, a security analyst, and an API architect — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.
Story 1: API Integration
Imagine you're a developer. Understand versioning strategy before integrating with an API (Application Programming Interface).
Why it matters: Choose the right API (Application Programming Interface) version for integration.
Story 2: Security Assessment
Imagine you're a security analyst. Discover older API (Application Programming Interface) versions that may have known vulnerabilities.
Why it matters: Identify deprecated API (Application Programming Interface) versions for security testing.
Story 3: API Design Research
Imagine you're an API architect. Study how other APIs implement versioning for best practices.
Why it matters: Learn from industry API (Application Programming Interface) versioning patterns.
Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the API Version Detection tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:
During sales prospecting, to qualify a lead by what they are running.
During competitive research, to understand what a rival is built with.
When scoping an integration or partnership.
When you suspect a target is using a known-vulnerable version of something.
If you can see yourself in even one of those bullets, the API Version Detection tool will pay for itself the first time you use it.
Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the API Version Detection tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.
The easiest way: just ask your AI assistant
If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:
"Use the API Version Detection tool to check api.example.com and explain anything that looks wrong in plain language."
The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.
MCP (Model Context Protocol) access is free on every plan, including the free tier. One API key works for both REST and AI — you do not have to choose.
The technical way: call it from code
If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.
# Replace edns_live_YOUR_KEY with your real API key from the dashboard
curl -H "Authorization: Bearer edns_live_YOUR_KEY" \
"https://api.edgedns.dev/v1/domain/api-version?domain=api.example.com"What you need to provide
There's just one piece of information you need to provide. The table below explains exactly what it is and what a real value looks like.
| Field | Type | Required? | What it means | Example |
|---|---|---|---|---|
domain | string | Yes | The domain to analyze API (Application Programming Interface) versioning for | api.example.com |
What you get back
When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.
| Field | Type | What you'll see in it |
|---|---|---|
domain | string | The queried domain |
detected | boolean | Whether API (Application Programming Interface) versioning was detected |
versioningMethod | string | Detected strategy: URL-path, header, or none |
currentVersion | string | Default/current API (Application Programming Interface) version |
supportedVersions | array | Available API (Application Programming Interface) versions discovered |
headers | object | Version-related headers (apiVersion, acceptVersionSupported) |
recommendations | array | API (Application Programming Interface) versioning improvement suggestions |
Words you might be wondering about
If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.
API (Application Programming Interface) — A way for one program to ask another program for something — like a waiter taking your order to the kitchen.
URL (web address) — The full address of a page, like https://example.com/about.
JSON (JavaScript Object Notation) — A lightweight format for sending data between programs. Looks like { "name": "example", "age": 5 }. Used by basically every modern web API.
Need Programmatic Access?
Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.