The API Layer Is Quietly Becoming the Storefront for Agentic Commerce
Cross-border sellers have spent a decade optimizing the human-facing funnel: listing images, A+ content, ad creative, checkout flow. But the next wave of buyers — and the next wave of intermediaries — aren’t humans clicking through a PDP. They’re agents calling endpoints. When your product data, inventory, pricing, and fulfillment logic live behind APIs that no agent can reliably discover, authenticate against, or recover from when a call fails, you don’t have an agent-ready business. You have a website. That gap is exactly what the launch of Elva by Theneo is poking at, and it’s worth more of your attention than another ad-spend dashboard.
What Elva Actually Solves (And Why It Isn’t Just a Dev Tool)
The pitch from maker Ana Robakidze is deceptively simple: connect your repo, and Elva builds an API catalog, maps how the API is used, and runs what they call “AI readiness” checks — no spec required. From there you define contracts around real use cases, picking the endpoints and fields a specific customer, partner, or agent needs. Those contracts can be published to docs platforms like Theneo or Mintlify, to mocks, or to hosted MCP servers. When code changes, you either auto-sync or route the drift into a review workflow.
For a cross-border operator, the interesting part isn’t the docs generation. It’s the contract layer. Most DTC and marketplace sellers I talk to have a Frankenstein stack: Shopify for the storefront, Amazon Seller Central for the marketplace, a 3PL’s API for fulfillment, a returns portal, a subscription tool, and a pile of internal scripts. Every one of those is a surface an agent might eventually need to touch — a procurement bot checking stock, a repricing agent pulling competitor data, a customer-service agent issuing a refund. Elva’s framing is that the contract, not the endpoint, is the unit of governance. That’s a meaningful shift.
Why Amazon sellers should care more than Shopify ones
Shopify merchants with a single store and a handful of apps can mostly ignore this for another year. Amazon FBA brand owners cannot. The moment you’re running SP-API integrations, a repricer, a review automation tool, and a multi-marketplace inventory sync, you already have an API surface that’s sprawling and undocumented. Add an AI agent on top — say, one that watches for Buy Box loss and adjusts bids — and you’ve got an agent making decisions against endpoints nobody has formally contracted. Elva’s positioning that “some customers get more API calls from agents than humans” is the tell. If that’s already true for Theneo’s customers, it’s coming for yours.
How It Differs From What You’re Probably Using Already
The obvious comparison is Postman, which Robakidze openly says she was “fed up with” four years ago. Postman is a request-building and testing tool; it’s excellent at the human-in-the-loop debugging workflow. It is not a contract governance layer, and it doesn’t publish MCP servers. The second comparison is Mintlify or ReadMe on the docs side — but those are presentation layers, not readiness evaluators. The third, and the one I’d watch most closely, is Stainless and Speakeasy, which generate SDKs and specs from OpenAPI definitions. Elva’s angle is that it works without a spec, which matters enormously for sellers whose “API” is really a set of undocumented internal endpoints behind a 3PL or ERP.
The MCP hosting piece is where Elva is most differentiated. Most teams rolling their own MCP servers are doing it badly: no auth scoping, no per-tool authorization, no analytics. When Pratik Sharda asked how one server serving different audiences keeps auth and analytics separate, Robakidze’s answer was the most technically substantive in the thread — each audience treated as a distinct tenant, per-tool and per-resource authorization, tenant identifiers carried through the full execution path, audit logs scoped by tenant with redaction and retention policies. That’s the level of rigor enterprise buyers will demand, and it’s the level most in-house MCP builds won’t reach.
The “no spec required” claim is the real wedge
If you’ve ever tried to get an OpenAPI spec out of a mid-tier 3PL or a legacy ERP vendor, you know the pain. Elva’s repo-connection approach sidesteps that. Whether it works cleanly on a polyglot codebase with a decade of technical debt is a different question — and one the launch thread doesn’t fully answer.
What Cross-Border Sellers Can Borrow From This Playbook
You don’t need to buy Elva to steal its mental model. Three things are immediately portable.
First, treat your integration surface as a product. Write down every external API your business depends on — payment processor, 3PL, marketplace, tax engine, returns tool. For each, note who owns it, what happens when it changes, and whether you’d notice a breaking change before your customers do. Most sellers I’ve audited can’t answer the third question.
Second, define contracts around use cases, not endpoints. Elva’s contract model — pick the endpoints and fields a specific consumer needs — is exactly how you should scope access for any internal tool or external partner. A freight forwarder doesn’t need your full order API. A repricing agent doesn’t need customer PII. Least-privilege isn’t just security hygiene; it’s how you keep an agent from hallucinating its way into a bad call.
Third, instrument agent activity separately from human activity. The thread surfaces a question from Naim Azoutar about agent keys so you can see which agent did what. Robakidze confirms Elva tracks which agent and user is using which tool, which tools are failing, and collects feedback from the agent when something breaks. If you’re running any AI tool against your storefront or marketplace data this quarter, you should be able to answer “which agent made this change” within sixty seconds. If you can’t, you have a governance problem you haven’t met yet.
Where the math breaks
Here’s my honest read: Elva is priced and positioned for engineering-led companies, not for a seven-figure Amazon brand with two developers. The value only materializes when you have enough API surface — and enough agent traffic — that manual governance breaks. Below that threshold, a well-maintained Postman collection and a Notion doc will do. The “AI readiness” scoring is also a black box from the outside; Robakidze lists the criteria (tool discoverability, schema clarity, parameter descriptions, auth flows, response consistency, error handling, context efficiency), but there’s no published rubric, and no way to compare your score against peers. That’s fine for a v1, less fine when a board asks why you’re paying for it.
Where My Judgment Says It Falls Short
Three concerns, in order of severity.
One: the “no spec required” claim needs a stress test. Robakidze says Elva builds a catalog from your repo without a spec. That’s plausible for a clean FastAPI or NestJS codebase. It’s much harder for the spaghetti most sellers actually run — a mix of legacy PHP, a Shopify app, and a 3PL’s SOAP endpoint. Until I see it run on a genuinely messy codebase, I’d treat this as a “works on greenfield” claim.
Two: MCP is still a moving target. The protocol is young, and the tooling around it is churning fast. Elva is betting that hosted MCP servers with auth and observability become a durable category. That bet could be right, or MCP could get absorbed into platform-native tooling from OpenAI, Anthropic, or the cloud providers within eighteen months. If you’re evaluating Elva, ask what happens to your contracts if MCP loses to a competing standard.
Three: the model-dependency problem is real and acknowledged. When Maia Mefarishvili asked whether the tool set scales for an API with many endpoints, Robakidze’s answer was refreshingly honest: it depends on the model. Some models handle large tool counts well; others don’t, and Elva recommends splitting MCP into multiple catalogs by use case. But — and this is the gap — the splitting is manual via an AI assistant, not automatic. Robakidze even says she’s “writing it down” as a feature request. For a seller with hundreds of SKUs and dozens of endpoints, that’s a lot of manual catalog design.
Why the “AX is the new DX” framing matters
Robakidze’s response to Rahul Arulkumaran is the line I’d underline: “AX is becoming as important as DX.” Agent Experience as a first-class discipline alongside Developer Experience. For cross-border sellers, this is the strategic signal. The brands that win the next three years won’t just have clean product data and fast shipping — they’ll have APIs that agents can discover, authenticate against, and complete real tasks with, end to end. Elva is one bet on that future. There will be others.
What I’d Watch / Test Next
This week, do three things. First, inventory your external API dependencies — every tool, every integration, every marketplace endpoint — and flag which ones have no documented owner or change-notification process. That list is your real risk register. Second, if you’re running any AI agent against your store or marketplace data, isolate its credentials today. Give it its own key, scope it to the minimum endpoints it needs, and log every call. You’ll learn more in a week of that than in a month of reading launch threads. Third, if you’re evaluating Elva specifically, run it against your messiest repo first — not your cleanest. The value proposition lives or dies on whether it handles the codebase you actually have, not the one you wish you had. And watch the MCP standardization fight closely; whoever wins that determines whether tools like this become infrastructure or become features.
