Seshen-Prism Platform
Developer Documentation

Overview

Seshen-Prism is delivered as infrastructure: each tenant gets an isolated memory vault (its own database — corpus, embeddings, and knowledge graph), accessed through a metered, OpenAI-compatible gateway, and exposed to agent runtimes through per-tenant MCP endpoints.

The gateway is the single door for every model call: per-tenant bearer keys, alias routing, cache-aware token metering, and hard spend caps. Seshen runs its own operations on this same stack.

Quick start

Every tenant holds its own bearer key (sk-seshen-…). With a key, the gateway speaks the OpenAI chat-completions protocol:

# Replace $SESHEN_KEY with your tenant key
curl https://gateway.seshen.co.ke/v1/chat/completions \
  -H "Authorization: Bearer $SESHEN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [{"role": "user", "content": "Why did we standardise on Storable products?"}]
  }'

The response is a standard chat-completion object. Your vault context is retrieved and synthesised server-side, and every token is metered against your tenant.

Model names are gateway aliases — see the Models table below for what's routable.

Gateway API

Base URL: https://gateway.seshen.co.ke/v1

Responses are standard and cache-aware: repeated prompts reuse cached tokens, and only net-new work is billed.

Models

The gateway routes model names per tenant plan. These aliases are live on the production gateway:

Pass any alias as model in your request; the gateway resolves it to the underlying model and meters at that route's price.

Authentication

Authenticate with your per-tenant bearer key. Keys are validated server-side on every request and cannot be read from the client.

Authorization: Bearer sk-seshen-<tenant>-<secret>

• One key per tenant — rotate by requesting a new key from your provisioner
• Spend caps are enforced at the gateway, so a leaked key has bounded blast radius
• No accounts or passwords on the platform itself — the key is the identity

Vaults & isolation

Each tenant's memory vault is a separate database — the isolation boundary is storage-level, not API-level. No tenant can query another tenant's vault, and no shared schema crosses tenant boundaries.

• Corpus, embeddings, and knowledge graph live inside the vault
• Vaults are provisioned by the Seshen console (self-serve provisioning is on the roadmap)
• Vault capacity is bounded by your tier — see Pricing

Usage & metering

Every request is metered at the gateway — cache-aware, per-tenant, to the fraction of a cent. Query your usage any time:

curl https://gateway.seshen.co.ke/v1/usage \
  -H "Authorization: Bearer $SESHEN_KEY"

The console shows usage parity with the gateway's own metering — one source of truth for what every tenant spends. Spend caps are hard limits: when a tenant hits its cap, further calls are rejected until the next cycle.

MCP endpoints

Every vault is exposed through a per-tenant MCP endpoint, so any agent runtime — Hermes, Claude, Codex, or your own orchestration — can read and write institutional memory over the standard Model Context Protocol.

• Point your MCP client at your tenant endpoint with your bearer key
• Tools expose vault search, retrieval, and knowledge-node classification (Fact / Opinion / Official Stance)
• Epistemic Receipts come back with every synthesis, giving you the provenance trace per answer

Status

Something missing? Email the team — we answer personally.