Own product · In production

Marketplace stores in Claude

An own product: the service connects a seller’s marketplace stores to Claude as a connector. 48 tools across three marketplaces, an API catalogue on top of the specifications, marketplace keys encrypted in the database, and a writing call that takes two steps: a preview first, then the send.

The pain

To understand what is happening in a store, a seller walks three marketplace accounts and merges reports in a spreadsheet. A dashboard answers only what was built into it.

Now

The seller asks in plain words - «what is running out», «is the advertising paying off», «how much will land on my account» - and Claude goes into the marketplace API with their key.

Effect across the steps

03 · Precise decisions: A question about the store is closed by an answer in words, not by merging reports
04 · From routine to automation: The daily round of three accounts collapses into one question in chat

What the business gets

The answer is assembled from the marketplace API right now, not from an export a week old.
You can ask what no dashboard holds: the API catalogue opens almost any method of the specification.
One marketplace’s key opens no other marketplace’s stores - checked on every call, not declared.
Even with full access to the database, other people’s keys cannot be extracted: they are stored encrypted.

From source to result

A question in plain words
The marketplace connector
Tools and the API catalogue
Marketplace API with the seller’s key
An answer as rows, not a file

Each marketplace has its own connector with its own address and access key. A writing call does not go out first time: the tool returns a preview, and the send happens only on a second call.

How it works

The API catalogue is built from snapshots of the marketplace specifications, so almost any method is available to Claude: find it by words, inspect its parameters, call it.

Before every release, watchdogs compare the methods the service calls from code against the specification snapshots: if a method is marked deprecated or has disappeared, the release stops. The rule appeared after a method turned out to be deleted after the code for it was written - three times in a row: the tests went into a mock, the mock answered in the shape of a dead endpoint, and everything was green.

The marketplace hands tabular reports over as files; the service downloads them and shows them as rows: the first two hundred as text, up to five thousand in a structured answer, the rest by paging.

Who maintains it now

Me. This is an own product rather than a client system: the key stays under the seller’s control - held in the database encrypted and revocable by them at any moment - and access to the service is granted by an invite code.

Other cases for this step

Internal system · In production

Data platform

The number is verified against the source down to a single unit

The pain: Data went through four processing layers and nobody compared the result with what the marketplace shows. Decisions rested on a number with nothing to check it against.
Now: Orders, cancellations and stock reconcile with the marketplace down to a single unit, money down to the kopeck, and the check can be repeated any day with one command.

Verified against
Data marts: sales, stock, presence, P&L, reconciliation

The same system pays off across 2 more steps

Internal system · In production

Advertising management agents

Bids move on data: the DRR plan is ≤ 10 %

The pain: Bids were moved on yesterday’s report and on a hunch. But «yesterday» does not show what actually happened, and a market-wide drop is easily mistaken for your own mistake.
Now: A decision is assembled in order: market regime, product health, the fair target DRR for this item, and only then the bid itself. Metrics come from a matured window; the DRR plan is ≤ 10 %.

DRR
Decision order: market regime → product health → target DRR → bid
Metrics window

The same system pays off on one more step

Open source · In production

Marketplace knowledge base for agents

The agent answers by the marketplaces’ rules, not from memory

The pain: When an AI agent designs logic against a marketplace’s rules, it leans on memory. Tariffs and limits change, memory does not, and errors surface in money, not at review.
Now: A knowledge base of three marketplaces sits next to the project as ordinary markdown files: one per API method plus the seller help. The agent reads the source, not a retelling.

The base
The build
Updating: one command, the git diff as the change report

GitHub

Internal system · Pilot

Marts on top of the data lake

Margin per product - and, separately, what does not land on it

The pain: Product economics were counted off the marketplace report. Cost price sits on logistics rows too, and there are far more of those - it came out an order of magnitude high.
Now: Two marts: one holds what honestly lands on a product, the other storage, intake, penalties and withholdings that do not spread across items. On screen they are a separate block, not profit that is absent.

The operation-type filter
What the dashboard answers from
The period ceiling

15 % of the source’s non-empty tables serve data older than a week, and the catalogue does not tell them from the live ones

Type: Own product
Status: In production
Coverage: 3 marketplaces, 48 tools
Keys: encrypted in the database
Replaced: walking the accounts and merging reports

TypeScriptMCPHonoNext.jsPrismaPostgreSQLVitestGitHub Actionsnginx

mcp.hubmarket.ru