Build on the backend
we run for you
The MixShift Builder Platform is the infrastructure layer under everything we ship: one OAuth credential that opens your warehouse, live retail and ads surfaces from Amazon, the brand memory behind why your numbers moved, MixShift Intelligence's attribution reads, and an MCP server for AI tools. Your apps, your workflows, your agents, on data we keep fresh for you.
Included with your MixShift subscription · REST API + MCP · Live with early partners now
A credential, a token, a query
Get a credential
Your tenant admin mints a service credential in the MixShift admin console, or we set one up with you. Read-only by default, revocable at any time.
Mint a token
Exchange the credential for a short-lived bearer token with a standard OAuth client_credentials grant. About an hour of life; re-mint on a 401.
Call anything
SQL against your warehouse, the /v1 data plane, or a cataloged operation against the SP-API or Ads API. Same token, same gateway.
curl -sS https://mcp.mixshift.io/oauth/token \
-H 'Content-Type: application/json' \
-d '{"grant_type":"client_credentials",
"client_id":"svc_abc123...",
"client_secret":"..."}'
{ "access_token": "eyJ...", "expires_in": 3600 }curl -sS https://mcp.mixshift.io/api/query \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H 'Content-Type: application/json' \
-d '{"sql":"SELECT campaignName, SUM(cost) AS spend
FROM campaign WHERE SellerID = ?
GROUP BY 1","params":[12345]}'
{ "ok": true, "rows": [ ... ], "rowCount": 42, "durationMs": 412 }What people are building on it
Not demos. These run today, on the same credential flow you saw above.
A featured-offer check that runs before you wake up
Our own account team runs a scheduled Claude task on a service credential. Every morning it batch-checks featured-offer pricing across a client catalog through the SP-API pricing surface and posts a summary of any ASINs that lost the featured offer. No dashboard, no manual pull; the schedule holds the credential and the platform does the rest.
The warehouse, synced into their own stack
An agency pages yesterday’s rows out of their MixShift warehouse every night with /api/query and lands them in their own database, feeding the BI dashboards they already had. The credential lives on their scheduler; there is no MixShift UI in the loop at all.
A product built on the /v1 data plane
Helm’s retail analytics reads accounts, daily sales and traffic, and Search Query Performance through the versioned /v1 endpoints: OAuth consent, scoped read-only tokens, cursor pagination. Their product, our plumbing.
{
"days": [
{ "date": "2026-07-01",
"sales": 48210.55,
"orders": 1093,
"currency": "USD" },
...
]
}Their own tools, straight on the REST API
The team at Ecommerce Wala builds tools for the brands they manage directly against the API, no MCP in the middle. Same credential, same gateway; the MCP stays available for the days they’d rather ask Claude.
Your builds on the left. Your data on the right.
One OAuth 2.0 gateway with per-credential scopes sits between your builds and the data. Whatever you build, it authenticates once and reaches your warehouse, the Ads API, and SP-API retail through the same contract.
Everything behind one gateway
Warehouse API
Read-only SQL on your own tenant database, plus contract-stable /v1 endpoints. Isolation is structural: your credential resolves to your database and nothing else.
Live Amazon passthrough
A published catalog of operations against the SP-API and Ads API, listed by the gateway itself. Reads across the board, plus audited writes for campaigns, bids, budgets, keywords, and negatives.
Brand memory
The part that knows why the numbers moved. Read the brand context your team maintains, read the change log of what happened, and append the launches, promotions, and stockouts that explain a move.
MCP server
The same gateway speaks the Model Context Protocol over streamable HTTP, so your AI tools can query your warehouse and act on your accounts in plain language.
Intelligence
MixShift Intelligence: finished reads served as data. Attribution today (why sales and ad results moved, lost sales, the monthly read); Forecasting joins the same catalog, starting with a readiness check for whether a merchant has the history to support one.
Skip the developer applications
Calling the Ads API and SP-API yourself means two separate developer registrations, security reviews, and role approvals before your first request. On the Builder Platform there is nothing to apply for: your accounts are already connected, so you start building today.
No registrations
No Ads API developer application. No SP-API security review. No role approvals. We already hold them, and you build on our registered application.
Already authorized
The seller and advertiser authorizations for your accounts already exist on MixShift. A new build reuses them the moment your credential is minted.
No token plumbing
Login-with-Amazon token minting, refresh, and regional routing all happen server-side. You hold one credential and call one gateway.
Safe by default. Audited when it acts.
Dry-run writes
Every write validates, snapshots current state, and returns a preview. Nothing reaches Amazon without an explicit commit.
Scoped credentials
Read scopes per domain; the write scope is opt-in per credential. Rotate or revoke any credential at any time.
Audit trail
Committed writes are capped per call and logged with the pre-write snapshot, so every change is attributable and reviewable.
Your data only
A credential resolves server-side to your own tenant database over a read-only connection. Isolation is structural, not a filter.
Published limits
240 requests per minute per credential, 50,000 rows and 10 MB per response, 120 second query ceiling. Real numbers, documented.
Latest platform releases
A readiness check opens the Forecasting service
The first Forecasting request answers a narrower question ahead of the forecast itself: does a merchant have the sales and ad-spend history to support one. It reports the trainable overlap against the required floor, the first month a real forecast could run, and what would close the gap, at either a single seller or a brand scope of several sellers summed month by month. It fits no model itself; the forecast that reads its answer joins the same catalog as it ships.
Per-ASIN evidence on lost sales estimates
A Lost Sales read with evidence turned on now includes the per-ASIN rows behind the total, not just the headline number, so a large estimate can be checked against the individual stockouts, buy-box losses, and ranking drops that produced it.
Placement and audience bid adjustments for Sponsored Products and Sponsored Brands
Set placement modifiers (top of search, product pages, home, detail page, rest of search) and audience-cohort modifiers on Sponsored Products and Sponsored Brands campaigns, previously a console-only change. Both ride the same dry-run-first, audited write path as every other campaign edit.
A unified reporting API, with history far past ninety-five days
Amazon Ads reporting v3 caps most report types at roughly ninety-five days of lookback. The new unified Reporting v1 surface reaches back up to two years at daily grain and six years at monthly or yearly grain, and spans every ad product in one report, DSP included, so a lookback that used to mean stitching several exports together is now one request.
FBA stock position on /v1
Read current FBA inventory straight from the warehouse: on-hand units, days of supply, and the health alert Amazon assigns, per ASIN, plus a daily on-hand series for trend and stockout work. Filter the snapshot to what is actually at risk instead of paging the whole catalog. Inventory joins advertising, retail, and Search Query Performance as a fourth reported data domain.
Marketing Cloud queries must state their own time window
An AMC query carries no dates of its own, so the window comes entirely from the request, and Amazon defaults it to a single day. A query written to cover a year would quietly answer for one day, with no error and no warning. Submitting an execution without a time window is now refused outright, with a message naming the options, rather than returning a confident wrong number. Any of the three window types is accepted; the point is that the choice is yours rather than the default’s. Prefer UTC bounds: a local time zone is converted forward, so a window ending at local midnight reaches into the next UTC day and shows up as a spurious extra period in anything grouped by date.
Check a paid AMC dataset before querying it, and read one table at a time
Two additions for Marketing Cloud work. Asking about an instance now returns which paid datasets are switched on for it, so a query that fails because the advertiser is not subscribed can be told apart from a query that is wrong: Amazon’s own message never mentions the subscription. And you can now ask for a single named table’s schema instead of paging the entire catalog to find it, which also removes the trap where an unpaged catalog read looked like the table did not exist.
Common questions
Start building
The data is already pulled, normalized, and waiting. One credential stands between you and your first query.