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 when it ships.
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
MixShift Intelligence open to every account
MixShift Intelligence is open by default for every account and documented on the Builder Platform as the fifth surface. Reach it through the REST endpoints or the MCP tools under the intelligence:read scope, no separate application required. Every catalog request now reports the service it belongs to, and each account can run up to two computing requests at a time.
Creative Asset Library lookup
Look up the newest assets in a profile’s Creative Asset Library: asset ids, type, approval status, and which ad programs each one already qualifies for. Returns the newest page for that profile rather than the whole library, which is enough to find something just uploaded in the console or to check eligibility before building an ad around it.
Sponsored Brands ad creation
Create Sponsored Brands ad groups and the ad itself: brand video, video, product collection, or store spotlight, each with its own creative shape. Every video and logo has to already exist in the Creative Asset Library, and every advertised product has to appear on the Store page shoppers land on. Amazon validates the creative when a change is committed rather than during preview, so building a batch means committing one ad first and reading its result before sending the rest.
Service-credential access tokens now last 12 hours
Service-credential access tokens now live for 12 hours instead of one. A scheduled job, a CI run, or any other unattended integration that reads its token once at startup no longer needs to refresh mid-run just to survive an hour-long window. Revoking a credential still stops new tokens from being minted; an outstanding token simply runs out on its own within that same 12-hour ceiling.
Raw SQL access is now a separate scope
Caller-authored SQL against your warehouse now needs its own scope, sql:query, alongside the domain read scopes. It gates the raw-SQL endpoint, the table and column discovery endpoints, and the equivalent MCP tools; the named-query catalog and the typed /v1 endpoints stay reachable without it. That makes least-privilege minting possible: build a credential that runs named queries and calls /v1 without ever handing it license to write its own SQL. Every credential minted before this change was backfilled with sql:query, so nothing already running broke. Mint one afterward with an explicit scope list, and you need to request sql:query by name.
Know which filters a query actually applied
Every successful named-query response now lists the parameter names that execution bound. Entry schemas are deliberately tolerant, so a filter a deployment does not recognise is dropped and the query still succeeds: useful for deploying your integration and the platform on separate schedules, but it meant a dropped filter looked exactly like an applied one. Now you can check the parameter you sent came back before treating the result as filtered. Names only, never values.
Sub-brand label discovery and filtering
For sellers running several distinct brands under one Amazon account, separated only by a brand label on the retail and ads records: new queries report the distinct labels on each side, how much of the catalog or ad spend carries no label yet, and how well the retail and ads labels agree with each other. The queries behind brand context also take optional retail and ads label filters, so a single brand can be read on its own instead of the whole account.
Common questions
Start building
The data is already pulled, normalized, and waiting. One credential stands between you and your first query.