Resources
SwiftXEO exposes a workspace-scoped REST API, an MCP server with OAuth, and signed inbound webhooks — every write surface is propose-only, and approval stays with signed-in humans.
Connect Claude, ChatGPT, Cursor, or a custom system to approved Business DNA, objectives, and active learnings — and contribute evidence and proposals back through the same human review that governs everything else.
Core doctrine
An agent connected through the API or MCP can read the approved context its credential is scoped to — Business DNA, active learnings, objectives, lineage — and do useful work grounded in it. It can observe things worth reviewing and propose a lesson worth learning. What it cannot do is decide that its own conclusion is correct.
No scope, tool, or webhook payload can approve or activate a learning. That decision happens inside SwiftXEO, by an authorized human through the destination's own review and approval rules — for learning activation specifically, an admin or workspace owner.
Open Platform principles
Credential-bound access
The workspace is derived from the key. It cannot be selected or overridden by a request parameter.
Read approved context
Business DNA, active learnings, objectives, and lineage (decision and execution history) — the same record the product shows a human.
Propose, never approve
External writes land pending. No scope reaches the authorization route.
Signed evidence intake
Webhook payloads are HMAC-verified and stored as connected context for review — never executed.
Untrusted by default
External material is stamped untrusted at ingestion. Promotion is a human decision, every time.
Projected, not raw
Responses are allowlist projections. Internal identifiers stay inside; reviewers appear as role labels, not names.
Authentication
Create a workspace API key under Settings → Infrastructure → Open Platform Access (workspace admin required). The secret is shown once; only its hash is stored. Read scopes are included from the Growth plan; write scopes require Execution and are re-checked at use time, so a plan change takes effect on the next request.
Authorization: Bearer sxk_live_k_xxxxxxxx_...
Business DNA snapshot, active learnings, objectives, and lineage
Workspace discovery search across topics, keywords, campaigns, briefs, and competitors
Propose learnings — always lands PENDING in the human review queue
Submit evidence, signals, or documents as connected context
Governed content generation — deducts workspace credits
Growth = consume approved direction · Execution = contribute to governed workflow
REST API v1
Every response uses the same shape — { data, meta? } on success, { error: { code, message } } otherwise. Reads are limited to 60 requests per minute per workspace, writes to 20. Generation deducts workspace credits before the model call.
Approved Business DNA snapshot — returned through a bounded allowlist projection
Human-approved (active) learnings, filterable by kind
Open growth objectives
Evidence, revision history, and human authorization for an entity
Propose a learning — PENDING until a human approves
Submit connected context for review
Governed content generation, credit-gated. Pass persist: true to save the result as a draft with provider/task provenance attached; otherwise the text is returned only
For longer-running external work, SwiftXEO can issue a bounded governed assignment tied to an objective, accept the resulting work product, and connect later outcome observations back to the same operating record.
Compile a bounded context assignment for one authorized objective — the scoped shape an external agent works from
Submit work product against a governed assignment — draft, evidence, or a learning proposal — landing pending human review. The assignment/result relationship is validated server-side; stale or invented assignment IDs are rejected
Report a qualitative or metric observation against an objective outcome, idempotent and subject to human review
curl https://www.swiftxeo.com/api/v1/context/dna \
-H "Authorization: Bearer sxk_live_k_xxxxxxxxxxxx_..."
curl -X POST https://www.swiftxeo.com/api/v1/learnings/propose \
-H "Authorization: Bearer sxk_live_k_xxxxxxxxxxxx_..." \
-H "Content-Type: application/json" \
-d '{
"kind": "content_learnings",
"category": "overclaim",
"lesson": "Avoid absolute performance claims without evidence.",
"evidenceNote": "Three campaign replies flagged the launch copy as overstated."
}'MCP server
The /api/mcp endpoint speaks stateless streamable HTTP. Currently tested hosted clients include Claude (web, desktop, mobile) and ChatGPT, which connect over OAuth: paste the URL, sign in, pick a workspace, approve access. Config-file clients such as Claude Code and Cursor use a static workspace key.
The tool list is filtered to the connection's scopes: read tools return approved context, write tools only propose. There is deliberately no approve, activate, or authorize tool at any scope.
Claude Code, Cursor & other config-file clients
claude mcp add swiftxeo \ https://www.swiftxeo.com/api/mcp \ --transport http \ --header "Authorization: Bearer sxk_live_k_xxxxxxxxxxxx_..."
Claude web, Desktop, mobile & ChatGPT
Add custom connector URL: https://www.swiftxeo.com/api/mcp → Sign in to SwiftXEO, pick a workspace, approve access. No key to paste — this connection uses OAuth.
Available tools
Draft updates remain draft mutations only. External revision cannot approve, authorize, lock, or publish the artifact, and a revised draft must pass fresh review before it can move forward.
Boundary
An API key or MCP/OAuth connection grants scoped, inbound access to SwiftXEO's REST API and tools — nothing more. It does not register the caller as an Agent Room teammate, and it never grants @mention visibility inside a workspace's Agent Room.
Agent Room teammates are a separate, fixed roster — Claude, OpenAI, Gemini, the SwiftXEO Advisor, and Verifier — each with its own routing and authority rules that no external credential can extend or bypass. A related but distinct system, the Local Connector protocol, pairs a local runtime (for example, a Mac running Agent Room tasks locally) with its own credential, lease, and revocation lifecycle — separate from both API keys and MCP connections.
Inbound webhooks
Create an inbound source under Settings → Infrastructure → Inbound Sources to receive a per-source endpoint and signing secret. Every payload is verified with HMAC-SHA256 over the raw body before it lands as connected context — material for human review, never truth on its own. Verification failure rejects the request before anything is parsed or stored.
Growth includes one active source; Execution allows multiple.
POST /api/hooks/{workspaceId}/{sourceId}
X-Signature: sha256=<hmac of raw body>
{
"kind": "signal",
"title": "CRM: deal closed",
"body": "Acme signed the annual
plan after the Q3 campaign."
}Questions
No. No API scope, MCP tool, or webhook can set a proposal to approved or reach the authorization route. External systems may read approved context, contribute evidence, and propose learnings — every proposal lands pending, and learning activation specifically requires an admin or workspace owner, signed in as a human user.
Two credential types on the same bearer header: a static workspace API key for config-file clients, or an OAuth access token for hosted clients like Claude and ChatGPT. Either way, the workspace comes from the credential — never from tool arguments.
Growth covers reads: Business DNA, objectives, active learnings, lineage, and workspace search, plus one inbound webhook source. Execution adds writes: proposing learnings, submitting evidence, governed content generation, and multiple inbound sources.
Role labels only. External responses are projected through a redaction layer: reviewer and author identities become "Workspace administrator", and internal identifiers are dropped before anything leaves the workspace.
The full platform reference lives in the documentation, and the Open Platform page explains the governance model these endpoints enforce.