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 everything your workspace has approved 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 once, inside the product, by a workspace admin — the same gate every internally generated proposal already passes through.
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 truth
Business DNA, active learnings, objectives, and lineage — 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 — an allowlist projection of organizational truth
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
curl https://www.swiftxeo.com/api/v1/context/dna \
-H "Authorization: Bearer sxk_live_..."
curl -X POST https://www.swiftxeo.com/api/v1/learnings/propose \
-H "Authorization: Bearer sxk_live_..." \
-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. Hosted clients — Claude web, desktop, and mobile, and ChatGPT in developer mode — connect over OAuth: paste the URL, sign in, pick a workspace, approve access. Config-file clients like Claude Code and Cursor use a static workspace key.
The tool list is filtered to the connection's scopes: read tools return approved truth, 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_..."
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
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.
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 truth, contribute evidence, and propose learnings — every proposal lands pending, and only a workspace admin signed in as a human user can approve it.
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.