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». 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, revocable 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, so 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