Skip to main content

// for tech partners

Build on Magistry's decision spine.

REST tool endpoints, an OpenAPI spec, and a remote MCP server with OAuth 2.1 and scoped API keys — the same tool registry that powers Otto and the dashboard, open to your integration. “Drive your whole store from your own AI.”

REST + MCP OAuth 2.1 + scoped keys Writes gated by approval cards

// why partners build on magistry

A decision spine you can extend, not a surface you have to skin around.

Most ecommerce platforms ask partners to wrap a UI. Magistry asks you to extend the decision spine — your integration earns the same audit trail, the same reversibility, the same kill switch as our first-party agents.
01

REST tool endpoints — the same registry Otto runs on

POST /api/v1/tools/{tool} with a scoped API key runs the exact tool registry that powers Otto and the dashboard — each tool tagged read, write, or write-approval, documented in the OpenAPI spec at /api/v1/openapi.json.

02

An MCP server, not just an API

Connect Claude, Cursor, or any MCP client to the remote MCP endpoint over OAuth 2.1 with store and scope selection. Full read surface under RLS; writes land as approval cards in the dashboard unless the operator opts into auto-apply.

03

Decision-log access through read tools

Query decisions, job runs, and evidence through the scoped read tools — build reporting layers, BI exports, finance reconciliation, or your own digest products on the same rows the dashboard renders.

04

Fine-grained scopes and keys you can defend

Per-resource, per-action scopes (ads:read, catalog:write, …) plus read/write/admin bundles. Mint keys on the Developers page, see the full tool catalog, and rate limits enforced server-side.

// this week

What you could ship on top of the spine this week.

Three integrations you could ship this week against the public surface — no private endpoints, no special access, same registry the dashboard runs on.
  • Pull the decision history into a BI warehouse through the read tools — one scoped, read-only API key, one nightly cursor.
  • Connect Claude Desktop to the MCP server over OAuth 2.1 — scoped to the stores you pick, every proposed write landing as an approval card in the operator's dashboard.
  • Propose catalog actions from an external research tool via /api/v1/tools — write-approval tools queue them for the operator; nothing applies without a card.

// from your dashboard

One API call. One proposed action. One approval card.

Submit an action through /api/v1/tools/{tool}; write-approval tools land as approval cards behind the same gates and reverse-op machinery as our first-party agents. Below: an example call proposing a discount.
POST /api/v1/tools/propose_discount
Authorization: Bearer mag_sk_live_***

{
  "sku":           "linen-blazer-stone-m",
  "discount_pct":  4,
  "window_days":   7,
  "rationale":     "sell-through ahead of plan,
                    margin headroom above floor"
}

← 200 OK
{
  "status":        "pending_approval",
  "proposal_id":   "prop_84217",
  "surface":       "approval card in dashboard",
  "gates":         ["kill_switch","rate_limit",
                    "cost_tier","margin_floor"],
  "docs":          "/api/v1/openapi.json"
}

// what your integration gets

Same judge. Same gates. Same reverse op.

Your integration isn't a second-class citizen — every gate that protects our first-party agents protects yours. Customers see your integration in the same decision_log, with the same kill switch.

/api/v1/tools/{tool} · /api/v1/openapi.json · MCP: /api/mcp · OAuth 2.1

// the API is the product

Built for partners who treat the API as the product.

The Magistry API exposes the same decision_log the product runs on, so an integration can read and reason about every action with full provenance — the foundation you'd want under a BI sync or a custom operator surface.

// build on the spine

The decision_log is open. Build something on top of it.

Mint a scoped API key on the free plan, connect your MCP client, and ship your first integration against the same tool registry Otto uses.

Operator-owned kill switch · Dry-run from day one