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 your own system to approved Business DNA, objectives, and active lessons. Send evidence and proposals back through the same human review as everything else.
The core rule
An agent connected through the API or MCP reads the approved context its credential is scoped to: Business DNA, active lessons, objectives, lineage. It can flag things worth reviewing and propose a lesson worth learning. What it cannot do is decide its own conclusion is correct.
No scope, tool, or webhook payload can approve or activate a lesson. That happens inside SwiftXEO, by an authorized person, under the destination's own review rules. Activating a lesson specifically requires 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 lessons, objectives, and lineage — the same record the product shows a person.
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 lessons, objectives, and lineage
Workspace discovery search across topics, keywords, campaigns, briefs, and competitors
Propose lessons — always lands PENDING in the human review queue
Submit evidence, signals, or documents as connected context
Reviewed 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) lessons, filterable by kind
Open growth objectives
Evidence, revision history, and the human approval for an entity
Propose a lesson — PENDING until a human approves
Submit connected context for review
Reviewed 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 external work, SwiftXEO can issue a scoped assignment tied to an objective, accept the resulting work, and link later observations back to the same record.
Compile a bounded context assignment for one authorized objective — the scoped shape an external agent works from
Submit work against an assignment — draft, evidence, or a proposed lesson — landing pending human review. The assignment/result link is validated server-side, and 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 has its own routing and access rules that no external credential can extend or bypass.
The Local Connector protocol is related but separate. It pairs a local runtime, such as a Mac running Agent Room tasks, with its own credential, lease, and revocation lifecycle. That is distinct 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 mark a proposal approved or reach the approval route. Outside systems can read approved context, add evidence, and propose lessons. Every proposal lands pending, and activating a lesson requires a signed-in admin or workspace owner.
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 lessons, lineage, and workspace search, plus one inbound webhook source. Execution adds writes: proposing lessons, submitting evidence, reviewed 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. The Open Platform page explains the review model these endpoints enforce.