A mock returns what you wrote. We return what production would.

01 / The structural difference

One issue, two trackers, and the PR that fixed it.

The three commands below follow one canonical backlog item across three hosts. The first two fetch the same issue from two different trackers — nobody wrote two response bodies; there is one simulated backlog underneath, and each host renders it the way that provider really would. The third follows the branch Linear names straight to the merged pull request that resolved it on the GitHub host. All three are pinned snapshot hosts, so every value printed here is a value you can still get back years from now.

# One canonical backlog item, three hosts. No setup, no key. Every host is a
# pinned snapshot: these bytes are frozen, so the values you get back today are
# the values you get back in two years.

# 1 — Jira REST: the item as a Jira ticket
curl -s "https://jira-v3.snap.sandboxapis.dev/rest/api/3/issue/ARGO-59?fields=summary,status,customfield_10016,labels"

# 2 — Linear GraphQL: the same item as a Linear issue — note branchName
curl -s https://linear-2026-08.snap.sandboxapis.dev/graphql -H 'content-type: application/json' \
  -d '{"query":"{ issue(id:\"ARGO-59\"){ identifier title estimate state{name} branchName labels{nodes{name}} } }"}'

# 3 — GitHub REST: that branch is the head of the PR that resolved it
curl -s "https://gh-2026-03.snap.sandboxapis.dev/repos/olympus-labs/parthenon/pulls/58"

Then the reference resolves across categories. Linear reports branchName: add-per-tenant-backpressure; fetch that branch on the GitHub host and it is the head of pull request #58, "WIP: Add per-tenant backpressure", merged into main on 2026-06-28. The tracker item and the git history are one event, rendered by three providers — not three fixtures kept in sync by hand.

Pinned hosts · frozen bytesThese are not a capture with a date on it. A pin regenerates byte-identically on every request, so the commands above return exactly these values today, next month, and in two years. The live hosts re-roll every day — same org, new activity — which is why the frozen demo runs against pins.

Azure DevOps renders the same canonical backlog as work items too — on its live host, https://ado.sandboxapis.dev, which re-rolls daily, and — because every provider is pinned in the same frozen generation — on its pinned host as well. The frozen demo above stays with Jira and Linear because they line up as the two cleanest dialects side by side.

Note what is not identical: the shapes are each provider's own. Story points arrive as customfield_10016 on Jira and estimate on Linear. Status is a Jira status object carrying a statusCategory on one host and a Linear workflow state with its own type on the other — both read Done here, but neither is the other's field. The dev branch is a first-class branchName on the Linear issue; the Jira issue resource doesn't carry it at all. Each provider's own vocabulary is preserved, because your client expects that vocabulary.

A mock tool is not wrong here — it is simply not in this business. To get the table above from stubs, you would author two response bodies, invent a shared identity for them, and then keep both in sync by hand every time the scenario changed.

03 / Capabilities, side by side

Where each tool actually wins.

Mock tools win more rows in this table than we do, and that is the honest result: they are a general-purpose instrument and we are a specific one. The rows we win are the rows you cannot get by authoring stubs harder. The third column is what most teams reach for first — a real account with a real token — and the rows it loses are the ones that end in a leaked credential or a mutated repo.

Vendors are named to identify the category, not to characterise any product's specifics. Each row describes what the category does by definition; check any vendor's own docs for their current feature set.

05 / Picking one

Which should you actually use?