AI & API
Point your agent, or your code, straight at your account.
One organization-scoped key, two ways in: connect an MCP client like Claude, or call a documented REST API from your own tooling.
Built for
Sellers and agencies who run AI tooling, and developers who want to build against their account directly. Bring your own agent, or write your own integration.
The gist
Market Monster puts your account behind one organization-scoped key with two front doors. Connect an MCP client and your agent reads inventory, orders, shipments, and finances, and can stage draft shipments you approve. Prefer to write the integration yourself? The same key calls a documented REST API, with an OpenAPI 3.1 spec and an interactive reference you can try in the browser. Same data, same guardrails, whichever door you use. And on Warehouse, one agency key answers across every client account you manage that is on Teams or above.
Why it matters
- One key, two surfaces: the same scoped key drives an MCP agent and a REST integration
- Read inventory, orders, shipments, sales, and finance events programmatically
- Every read is cited back to the exact rows it came from
- Writes only ever stage a draft you approve in the app; nothing here submits to Amazon or spends money
- A generated OpenAPI 3.1 spec and an in-browser reference, so the docs can never drift from what runs
- Scoped, rate-limited keys you can revoke anytime
- On Warehouse, one agency key answers a single question across all your client accounts on Teams or above
Two front doors
Both doors open onto the same organization-scoped data, with the same key and the same guarantee that no write reaches Amazon or spends money. Pick the one that fits how you work.
Bring your own agent · MCP
Connect the assistant you already use.
Market Monster is a native Model Context Protocol server. Point an MCP client at the endpoint, paste your key, and your agent can read your account and stage drafts, in the same conversation it uses to touch the rest of your stack.
- Works with any MCP client, such as Claude, Gemini, or ChatGPT, plus your own agents
- Ask in plain language and get answers grounded in your real rows, each one cited
- The same conversation can read Market Monster here and write to your spreadsheet, WMS, or repricer
- With the draft scope, an agent stages a complete shipment you review and submit in the app
- On Warehouse, an agency key fans one question across every client account on Teams or above
- 1Create a key in Settings, under API Keys.
- 2Add the MCP endpoint and key to your client.
- 3Ask away, and approve any drafts in the app.
Build your own · REST API
Call it straight from your code.
The same key calls a flat REST API under /api/v1. Every endpoint is described by a generated OpenAPI 3.1 spec, and an interactive reference lets you try calls in the browser before you write a line of code.
- A generated OpenAPI 3.1 spec at /api/v1/openapi.json that never drifts from the code
- An interactive reference at /docs/api with a try-it console
- Bearer-token auth: send your key in the Authorization header, with no organization to name
- Cursor-paginated reads, each response wrapped in a citation envelope
- Send an Idempotency-Key on writes; a retry returns the original result, never a duplicate
- Stable, machine-readable error codes, and a 429 that tells you when to retry
- 1Create a key in Settings, under API Keys.
- 2Send it as a bearer token to /api/v1.
- 3Read data, POST a draft you then approve in the app, or record what arrived in the warehouse.
Both doors share the same key, the same organization boundary, and the same rule that no write reaches Amazon or spends money.
Put it to work
- Attach live account data as context to your assistant, then ask what is running low or what shipped this week
- Ask why Amazon charged you and trace any fee back to its order, next to everything else that hit it
- Say "stage a shipment: 24 units of SKU X in two boxes" and find the draft waiting for your review
- Have your own warehouse tool post what arrived as it lands, so receiving, landed costs, and case packs stay current without a second entry pass
- Wire the REST API into your own dashboard, ERP, or scripts and pull inventory, orders, and finances on your schedule
- Build a nightly reorder report against your real cost layers, paging through every result with citations intact
- On Warehouse, ask which of your clients need restock and get every account on Teams or above answered in one pass
The toolbox
This is the whole surface, with nothing hidden: the tools an MCP agent sees, and the exact REST endpoints your code calls, side by side. Every operation is scoped to your account (there is no organization to name), reads are cursor-paginated and rate-limited, and every read response carries citations back to the rows behind it. The write scopes are siblings rather than levels, so a key can carry drafting, inventory writes, both, or neither, and each group below says which one it needs. REST paths are shown relative to /api/v1.
Read
every keyThe question-answering surface: stock, shipments, sales, and every Amazon charge.
| MCP tool | REST endpoint | What it does |
|---|---|---|
| search_inventory | GET /inventory/search | Fuzzy-find items by product name or a partial MSKU / ASIN. |
| list_inventory | GET /inventory | Page through inventory: available, on-hand, in-transit, and reserved counts with condition and list price. |
| get_inventory_item | GET /inventory/{id} | One item's catalog detail: title, brand, weight, prep category, and hazmat signal. |
| list_manifests | GET /manifests | Your shipment builds and their status, filterable by open / closed / locked. |
| get_manifest | GET /manifests/{id} | A manifest's header and line items, with prep, hazmat, and restriction flags. |
| get_manifest_boxes | GET /manifests/{id}/boxes | The packed boxes on a manifest: dimensions, weights, and contents. |
| get_manifest_shipments | GET /manifests/{id}/shipments | Which Amazon shipments a multi-FC placement split into. |
| list_shipments | GET /shipments | Inbound FBA shipments with lifecycle status, destination, and unit counts. |
| get_shipment | GET /shipments/{id} | One shipment's status, destination, and contents by its Amazon id. |
| list_sales_orders | GET /sales-orders | Sold orders with totals, dates, and status; filter by platform or date range. |
| get_sales_order | GET /sales-orders/{id} | Line items, the Amazon fee breakdown, and which inbound shipment supplied the units. |
| get_sales_order_profitability | GET /sales-orders/{id}/profitability | COGS, gross profit, margin, and ROI for one order, computed from your real cost layers and never estimated. |
| list_finance_events | GET /finance-events | Every Amazon charge and credit; filter by order, SKU, or a settlement window. |
| get_finance_event | GET /finance-events/{id} | One charge or credit in isolation. |
| trace_finance_event | GET /finance-events/{id}/trace | Answers "why did this charge happen?" with the full fee stack on that order plus the net. |
| list_inventory_receipts | GET /inventory-receipts | What physically arrived, when, at which site and bin, who booked it in, and against which cost layer. |
| list_inbound_deliveries | GET /inbound-deliveries | Every arrival on its way or already landed, with what was declared, what turned up, and the gap between the two. |
| get_inbound_delivery | GET /inbound-deliveries/{id} | One arrival in full: every SKU on it, the short or over reading per line, and the DEL number the warehouse writes on the paperwork. |
| list_storage_sites | GET /storage-sites | The places your stock physically sits, with receipt and delivery counts for each. |
| list_replenishments | GET /replenishments | Your cost layers: what you paid per unit, landed, and the full quantity ladder behind each purchase. |
| get_item_pricing | GET /item-pricing | One item's list, selling, and business price, with the Min and Max guardrails on record and where they came from. |
| list_price_snapshots | GET /price-snapshots | One SKU's captured price history, so you can see drift separately from your own writes. |
| get_pricing_settings | GET /pricing-settings | Your Automated Pricing pre-fill rule. Reading it never changes anything on Amazon. |
Draft
keys with the draft scopeWrites that only stage. An agent can build a complete draft shipment (lines, boxes, even LTL pallets), but a human always reviews and submits in the app. Nothing here touches Amazon or spends money.
| MCP tool | REST endpoint | What it does |
|---|---|---|
| draft_manifest | POST /manifests | Stage a new draft shipment build. |
| draft_manifest_line | POST /manifests/{id}/lines | Add a SKU and quantity to a draft. |
| update_manifest_line | PATCH /manifests/{id}/lines/{lineId} | Edit a line: quantity, packaging, costs, supplier, dates. |
| remove_manifest_line | DELETE /manifests/{id}/lines/{lineId} | Take a line off a draft. |
| draft_manifest_box | POST /manifests/{id}/boxes | Pack a box: dimensions, weight, and the items inside. |
| update_manifest_box | PATCH /manifests/{id}/boxes/{boxId} | Edit a box's dimensions, contents, or shipment assignment. |
| remove_manifest_box | DELETE /manifests/{id}/boxes/{boxId} | Remove a box from a draft. |
| update_manifest | PATCH /manifests/{id} | Patch the header and LTL freight details; switch parcel vs. freight. |
| set_manifest_pallets | PUT /manifests/{id}/pallets | Build the pallet plan for an LTL draft, box assignments included. |
| duplicate_manifest | POST /manifests/{id}/duplicate | Copy a past manifest into a fresh draft. |
| delete_manifest | DELETE /manifests/{id} | Delete an unsubmitted draft. |
Inventory
keys with the inventory scopeWrites that record what happened in your warehouse: what is on its way, what arrived, what it cost, and how it packs. A separate scope from drafting, not a bigger one, so a receiving integration can book stock in without being able to touch your shipments. These take effect when called, because a box on the dock has already arrived, and every one of them is corrected by a further call rather than by rewriting history. Nothing here touches Amazon or spends money.
| MCP tool | REST endpoint | What it does |
|---|---|---|
| announce_delivery | POST /inbound-deliveries | Open an arrival for stock on its way and declare what should be on it. Nothing moves until the units land. |
| receive_against_delivery | POST /inbound-deliveries/{id}/receive | Book what actually turned up against the arrival it came in on. A SKU nobody declared is accepted and stays visible; over-shipments are never blocked. |
| update_delivery_line | PATCH /inbound-deliveries/lines/{lineId} | Correct what was declared on one line. It never touches the received side, because units that arrived are a fact the paperwork cannot unmake. |
| delete_delivery | DELETE /inbound-deliveries/{id} | Cancel an announced arrival nothing has been booked against. Once units have landed it refuses, so real receipts are never quietly detached. |
| record_receipt | POST /inventory-receipts | Book units in against one or more SKUs, all in one transaction, routed to your oldest outstanding cost layers first. |
| clear_receipt | POST /inventory-receipts/{id}/clear | Write off units that left the shelf unseen. The one correction verb: receipts are never edited or deleted, because that would move your COGS silently. |
| create_replenishment | POST /replenishments | Record a purchase as a cost layer: units bought, the date, and the four landed-cost components per unit. |
| update_replenishment | PATCH /replenishments/{id} | Correct a cost layer’s costs, supplier, or purchase date. The bought quantity is deliberately fixed. |
| create_case_template | POST /inventory/{msku}/case-templates | Define a case pack: the carton and how many units are inside one. |
| update_case_template | PATCH /inventory/{msku}/case-templates/{id} | Change a case pack’s dimensions, weight, or units per case. |
| remove_case_template | DELETE /inventory/{msku}/case-templates/{id} | Retire a case pack. Boxes already built from it keep the dimensions they were built with. |
| set_default_case_template | POST /inventory/{msku}/case-templates/{id}/set-default | Choose which case pack the packing flow pre-fills for that item. |
| update_pricing_settings | PUT /pricing-settings | Write your Automated Pricing pre-fill rule. Local only: it changes what we compute, and pushes nothing to Amazon. |
Across every client
Warehouse · MCP agency keyThe multi-account lane, an MCP feature on the Warehouse plan. One agency key fans a single question out across every client account you manage and comes back grouped and cited per account. "Which of my clients are low on stock?" is one call, not a login loop.
| Tool | What it does |
|---|---|
| list_orgs | Every account your key can reach, with your role in each. |
| list_inventory_all | Inventory across all your clients at once, grouped per account. |
| list_manifests_all | Every client's shipment builds in one sweep. |
| list_shipments_all | Inbound shipments across all clients, with status. |
| list_sales_orders_all | Sold orders across all clients. |
| list_finance_events_all | Charges and payouts across all clients. |
The cross-account tools are an MCP feature on the Warehouse plan; the REST API is single-account. Each client account answers on its own Teams or higher plan, and accounts below that are listed by name and skipped, so you always know who was covered. With the draft scope, an agency key can also stage work into a specific client account. Inventory writes are deliberately single-account only: receiving stock into the wrong client is not a mistake worth making convenient, so use that account’s own key.
Start to finish
- 1Create a key in Settings, under API Keys, adding the draft scope to stage shipments and the inventory scope to record receiving, costs, and case packs.
- 2For an agent, add the MCP endpoint and key to your client. For code, send the key as a bearer token to /api/v1.
- 3Read your data, stage drafts, and record what lands in the warehouse.
- 4Approve any drafts in the app before they go anywhere.
What you'll need
A Teams or higher plan and an API key from Settings. For agents, an MCP-capable client such as Claude Desktop. For the REST API, any HTTP client, plus the interactive reference and OpenAPI spec at /docs/api. Keys are managed by admins, who can share them with the team. Agency keys are a Warehouse feature, and every client account you reach through one needs its own Teams or higher plan.
Quick answers
Is there a REST API, or only MCP?
Both, on the same key. Connect an MCP client for your agent, or call the REST API under /api/v1 from your own code. Both doors expose the same operations over the same account-scoped data.
Why an endpoint instead of a built-in AI chatbot?
A built-in chatbot is a walled garden: it knows one product's data and nothing else you run on. An endpoint inverts that. You bring the assistant or the code you already use, and Market Monster becomes one of its tools, right alongside your spreadsheets, your WMS, and your email.
The same conversation can read your live inventory here and write the reorder plan to a Google Sheet. No chatbot trapped inside a single app can do that.
This gap compounds, too. Every connector your assistant gains, Market Monster gains with it. A built-in bot only ever reaches the integrations its vendor builds and maintains, one at a time.
Can an agent or a script spend money or submit to Amazon?
No. Reads are read-only. Writes only ever stage a draft that you review and submit yourself in the app. Nothing in this surface submits to Amazon, buys a label, or spends money. Every write returns a receipt naming the draft it staged.
How do I explore the API?
Open the interactive reference at /docs/api. It renders a generated OpenAPI 3.1 spec, also served at /api/v1/openapi.json, and lets you try real calls in the browser. Because the spec is generated from the code, it can never drift from what actually runs.
How does authentication work?
Send your key as a bearer token in the Authorization header. The key is bound to one organization, and that binding is the whole boundary: there is no organization parameter anywhere in the API. Reads need a read key. The two write scopes are siblings: staging drafts needs the draft scope, and recording receiving, cost layers, case packs, or the pricing rule needs the inventory scope. You choose them when you create the key, and holding one never implies the other.
What does the agency key add?
On the Warehouse plan, an MCP agency key carries your whole client roster. The *_all tools fan one question out across your accounts and return the answers grouped and cited per client, so "who needs restock?" is one ask instead of a login loop. Each client account answers on its own Teams or higher plan; accounts below that come back listed by name and skipped, so the answer always tells you who it covered.
How do I turn off access?
Revoke the key in Settings and access stops immediately, on both the MCP and REST surfaces. A downgrade below Teams also cuts access, even for a key that still exists.
Explore more
Ready to put AI & API to work?
Private beta. Request early access and we'll bring you in as we scale onboarding.