01
API-first — every agent action is an endpoint
Read decision_log, write proposed actions through the planner, subscribe to gate outcomes. Whatever the in-app dashboard does, your integration does too.
// for tech partners
Build on Magistry's decision spine.
API-first, webhook-rich, decision_log-native. Ship apps, integrations, and channels on top of the orchestrator your customers already trust — backed by a partner program, dev docs, SDKs, and a sandbox tenant on day one.
REST + webhooks decision_log direct read Sandbox tenant day one
// 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.
02
Webhook surface covers the full agent lifecycle
decision.proposed · decision.applied · decision.reversed · agent.escalated · killswitch.flipped. Drive Slack, PagerDuty, Linear, or your own ops tooling off real-time events.
03
Direct decision_log access (read-only or audit-scoped)
Postgres-native, pgvector-backed, queryable. Build reporting layers, BI exports, finance reconciliation, or your own digest products on top of the same rows we use internally.
04
Partner program with build credits and co-marketing
Submit your integration, get sandbox credits, sample tenants, and a slot in the partner registry. We do not compete with you on the surface area you build.
// this week
What partners shipped on top of the spine this week.
Three real partner integrations, all built against the public API and webhook surface. No private endpoints, no special access — what you'd ship too.
- Shipped a 3-line integration against /v1/decisions — pulled 84,217 rows into the partner's BI warehouse with one daily incremental cursor.
- Subscribed to decision.applied webhooks for 6 tenants — drove a partner-built Slack digest that pings the right channel based on agent type and severity.
- Used the planner endpoint to propose 412 catalog actions from an external research tool — Magistry's judge accepted 387, escalated 8, rejected 17 with structured reasons.
// from your dashboard
One API call. One proposed action. One judged response.
Submit an action through /v1/planner; Magistry runs the same judge, the same gates, and the same reverse-op machinery as our first-party agents. Below: a partner research tool proposing a price change.
POST /v1/planner/propose
Authorization: Bearer mag_live_partner_***
Idempotency-Key: rsx-2026-05-25-44912
{
"tenant": "linen-house",
"actor": "partner:research-tool",
"action": "PRICE_CHANGE",
"sku": "linen-blazer-stone-m",
"delta_eur": -6.00,
"evidence_tier": "A",
"evidence_ref": "rsx://signals/2026-05-25/44912",
"dry_run": false
}
← 200 OK
{
"decision_id": 84217,
"status": "APPLIED",
"judge": "PASS",
"gates_passed": ["kill_switch","rate_limit","tier_A",
"trademark","uniqueness","budget"],
"reverse_op": "/v1/decisions/84217/reverse",
"applied_at": "2026-05-25T06:14:02Z"
}// 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.
docs.magistry.io/api · /v1/decisions · /v1/planner · /v1/webhooks · /v1/audit
// what tech partners are saying
From a partner who treated the API as the product.
“Otto answers my CFO's questions before they hit Slack — and the Magistry API answers our integration's questions before our engineers hit Slack. We built a full BI sync in a sprint, against the same decision_log Magistry uses itself.”
Emma Liu
Head of Retention & Partnerships
BREVARD
// build on the spine
The decision_log is open. Build something on top of it.
Apply for the partner program, claim a sandbox tenant, and ship your first integration against the same API surface our first-party agents use.
Kill switch ON by default · Dry-run from day one