Every cross-border e-commerce operation is now an integration business. The winner is not necessarily the one with the best product photos; it’s the one who can wire Shopify storefronts to Amazon FBA, TikTok Shop orders to 3PLs, and ad spend to inventory forecasts before the competition finishes reconciling a CSV. That wiring happens in API clients. So when a Windows-native API client called Karve landed on Product Hunt, it looked like a developer curiosity. It isn’t. Underneath the file-based syntax and the solo-maker story is a thesis every cross-border seller should steal: your operational data should live in files you control, not in someone else’s database.
The file is the source of truth
Karve is positioned as “the API client for developers on Windows.” The pitch is intentionally narrow: a native Windows app built around plain .http files, with a cold start under 2 seconds, environment switching, searchable history, and Git-friendly storage. Requests stay on disk. No account. Buy once. The maker, Pavel, explains that his API requests already lived as .http files in microservices repos, in the format used by editor REST clients like VS Code’s REST Client extension. But once those files spread across projects, there was no workspace for them. Every tool he tried to launch them with felt slow and heavy.
That is exactly the frustration I see inside serious cross-border operations. A seller running Amazon and Shopify will have a Postman workspace, a few cURL commands in Notion, and maybe a Google Sheet full of endpoints for the Amazon Selling Partner API or the Shopify Admin API. The API client is tribal knowledge. Karve’s answer is to make the file the system of record. It doesn’t import requests into a proprietary database; it organizes the .http and .rest files you already have, from any repo, without moving them. They keep diffing, branching, and reviewing like code.
For operators, this is a genuinely different mental model. Instead of building an integration library inside a cloud dashboard, you build it in a Git repository. Every change to a listing endpoint, every updated webhook payload, every new order-sync call becomes reviewable. If you’ve ever tried to debug a marketplace integration in a shared workspace, you know how fast chaos can spread when someone edits an environment variable and nobody notices. A file-based workflow gives you the same audit trail you already use for product listings and ad creative.
Why Amazon sellers should care more than Shopify ones
The Amazon seller ecosystem is still Windows-heavy. FBA workflows, Seller Central automation scripts, and third-party logistics integrations tend to live on Windows machines. A native Windows app with x64 and ARM64 support matters more than a pretty cloud app if your operations team is sitting on older ThinkPads in a Shenzhen or Xiamen office. Shopify merchants, by contrast, are disproportionately Mac and cloud-first. That is not a rule, but it is a pattern I keep seeing. Amazon SP-API work is usually an internal-tools problem; Shopify Admin API work is often a front-end and operations hybrid. Karve is aimed at the internal-tools builder, which is why I’d pay closer attention to it if I were running Amazon FBA than if I were running a DTC Shopify brand.
What Karve actually does differently
The incumbent comparison is easy. Postman has become the default, but it has also become heavy: account login, cloud sync, workspaces, team plans, and a browser-style wrapper that eats RAM. Insomnia solved the lightweight problem for years, but it also drifted into cloud-account territory, and the API design features can feel like overkill if you just want to hit a few endpoints. VS Code’s REST Client extension handles .http files beautifully, but it’s buried inside an editor that isn’t built for focused API work. The Product Hunt sidebar also lists Thunder Client and NativeRest as alternatives. All are plausible. None of them makes the three choices Karve makes.
The first choice: files stay files. The second: native or nothing. The third is the one that should make e-commerce operators pay attention. Karve ships a built-in MCP server, so Claude Code or any MCP client can find, run, fix, and author requests in the real workspace. But the agent only ever sees requests as raw text with {{placeholders}}. Resolved URLs, environment values, and stored history never cross to the agent. The server is off by default, localhost only, and controlled by a single toggle in Settings. That is a clever security posture: give AI agents the power to act on API workflows without handing them the keys to the kingdom.
This is the part that should make cross-border sellers stop scrolling. If you’ve connected a listing tool to your Amazon account, you know the risk: a third-party app asking for “read and write” access to your Seller Central or Shopify store can see everything. Karve’s MCP approach means an agent can operate on your collection of .http files, test a new supplier feed, or run a fulfillment status check, without ever resolving your actual OAuth tokens or environment secrets. The secrets stay on the machine. That is a more respectful security model than most SaaS integrations.
The MCP angle is the sleeper feature
For a single-user tool, MCP support seems almost strange. Why would an API client need to be agent-controllable? Because the next phase of e-commerce operations is not more dashboards; it’s agents operating under constraints. A seller might ask a coding agent to “update the product price feed” or “test the order-return webhook.” The agent doesn’t need the seller’s real API keys. It needs the request templates and placeholders. Karve’s design lets that happen safely. The maker’s launch comment puts the boundary clearly: the agent can find, run, fix, and author requests, but resolved URLs, environment values, and stored history never cross to it. That is the right boundary for a tool that will be used in an environment where one leaked credential costs you a storefront.
What cross-border sellers can borrow from it
This is not just a tool review for engineers. The launch contains at least five operational ideas worth stealing.
First, store API workflows as code. If you are a DTC brand selling on Shopify, Amazon, TikTok Shop, and Etsy, your integration endpoints are a map of your business. Put them in a repo with environment files. Next time an engineer or a VA asks “how do we call the returns endpoint?” you point them to a file. That is better than asking them to decode your memory.
Second, use plain-text request files with placeholders. The discipline of {{environment}} variables forces you to separate config from code. That is the same separation you should already have between marketplace credentials and your dashboard settings. When the marketing team gets access to a request file, they should not see your secret tokens.
Third, choose tools that don’t lock your data in their database. The phrase “files stay on disk, Git-friendly” is not a technical niche; it’s a portability guarantee. If you stop paying or the product dies, your requests are still there. You cannot say that about every SaaS tool in your stack. For a seller dealing with marketplace API changes every few months, that portability is worth real money.
Fourth, consider one-time purchase economics. Karve launched with a one-time purchase price of $29.99 with a 15-day free trial, instead of another $20 per month subscription. For a small operation, that math is meaningful. For a solo maker, it’s also a bet: every update has to earn a new buyer instead of relying on renewals.
Fifth, use the free converters. The Karve site offers free cURL/OpenAPI/HAR → .http converters, no purchase needed. If you have a Postman collection, an OpenAPI spec from a payment provider, or a HAR export from a browser session, you can start building a file-based API library today without paying anything. That is the lowest-friction onboarding I’ve seen from a small API client in a long time. Postman and cURL import are on the 1.1 roadmap, and the converters cover part of that gap in the meantime.
Where the math breaks
Let me not oversell. Karve is deliberately limited: REST only today, single-user, Windows only. WebSocket and Postman/cURL import are on the 1.1 roadmap. There is no team sharing, no cloud sync, no role-based access, and no collaboration. For a cross-border operation with multiple VA agencies, account managers, and a software team on three continents, that is a non-starter as the central API hub. You would not want every VA to install a Windows app and share .http files over Slack or WeChat. This is a tool for the operator who owns the system, not for a team.
The buy-once model also has a sustainability question. A $29.99 one-time purchase with MCP included and all 1.x updates covered is a great deal for the user. But the maker is a solo developer, and solo tools live or die by maintenance. If the product doesn’t hit escape velocity, the 1.x updates stop coming. The launch text says every 1.x update comes with the purchase — a promise that also implicitly defines a ceiling. I don’t hold that against a solo maker; I just wouldn’t build my entire integration stack on a tool whose roadmap depends on one person’s free time.
The buy-once economy cuts both ways
On one hand, buy-once is the best answer to subscription fatigue. Cross-border sellers are drowning in monthly fees for everything from email marketing to repricing to PPC analytics. A one-time purchase API client feels like a breath of fresh air. On the other hand, the reason SaaS pricing exists is that maintenance is ongoing. Marketplaces change APIs. Certificates rotate. Windows updates break things. If the maker gets discouraged and walks away, you own a static binary. That is more acceptable when the core value is local files than when it’s a cloud tool that disappears and takes your data with it. The local-first bet is the right bet, but it needs an exit path: your collections must stay exportable forever. Karve’s file-based design naturally provides that.
What I’d watch / test next
If you run a cross-border operation, here is what I’d do this week. First, download the 15-day trial and grab a few real API calls from your Amazon or Shopify integration scripts. Convert them to .http files, store them in a repo, and see whether the workflow feels more reviewable than your current setup. Second, test the MCP server with Claude Code on localhost. Give it a request file with placeholders but no real secrets, and see whether it can run and fix a request without you exposing credentials. That test alone is worth the download. Third, audit your API tooling spend. Count how many of your current testing and integration tools are subscriptions you barely use. If one of them is just a Postman workspace, Karve’s buy-once model may be a cheap way to cut recurring cost. Finally, watch the 1.1 roadmap for WebSocket and Postman import. If those land, this stops being a niche Windows tool and starts being a credible local-first alternative for sellers who want fewer accounts, fewer subscriptions, and more control over their own operational data.
