Models
/modelsDiscover model IDs visible to the key.
- Streaming
- —
- Note
- Key-scoped response; the example below is abbreviated.
API DOCUMENTATION
Authenticate with your Sealarca API key, discover the models available to that key, send Responses, Chat Completions or Claude Messages requests, and connect the service to your software.
The examples use a model ID returned by GET /v1/models. No model is fixed in this documentation.
First request
cURL · Responses
curl https://api.sealarca.ch/v1/responses \
-H "Authorization: Bearer $SEALARCA_API_KEY" \
-H "Content-Type: application/json" \
-d "{\"model\":\"$SEALARCA_MODEL_ID\",\"input\":\"Summarize this confidential text in three points.\",\"max_output_tokens\":256}"Response shape
JSON · Abbreviated response
{"id":"<response-id>","object":"response","status":"completed","model":"<model-id>","output":[{"type":"message","role":"assistant","content":[{"type":"output_text","text":"<generated text>"}]}]}START HERE
Follow the order below: access first, then model discovery, then a server-side request.
Create your Sealarca account to access the dashboard.
Top up your prepaid CHF balance before calling the API.
Create a Sealarca API key and keep it on your server.
Call GET /v1/models and choose an ID visible to your key.
Use the returned model ID with Responses, Chat Completions or Claude Messages.
The public API accepts a Sealarca API key as a Bearer token or, for Claude clients, through `x-api-key` on the Messages route.
Authentication headers
Use `Authorization: Bearer ...` for Responses and Chat Completions. Claude clients may use `x-api-key: ...` with `anthropic-version` on `/v1/messages`.
Authorization: Bearer $SEALARCA_API_KEYx-api-key: $SEALARCA_API_KEYanthropic-version: 2023-06-01Keep the key server-side
Never expose it in a public web application, distributed mobile app, repository, or NEXT_PUBLIC_* variable. Desk is a separate local client: the user provides the key and it is kept only for the tab session.
A server-side key, the base URL, and a JSON body are enough. The canonical example uses Responses.
Server-side key only. Never place the key in a public web application, browser bundle, `NEXT_PUBLIC_*` variable, Git repository, or distributed mobile app. A public web application must call your backend, which then calls Sealarca.
export SEALARCA_API_KEY="YOUR_SEALARCA_API_KEY"
export SEALARCA_MODEL_ID="MODEL_ID_FROM_V1_MODELS"
curl https://api.sealarca.ch/v1/responses \
-H "Authorization: Bearer $SEALARCA_API_KEY" \
-H "Content-Type: application/json" \
-d "{\"model\":\"$SEALARCA_MODEL_ID\",\"input\":\"Summarize this confidential text in three points.\",\"max_output_tokens\":256}"{"id":"<response-id>","object":"response","status":"completed","model":"<model-id>","output":[{"type":"message","role":"assistant","content":[{"type":"output_text","text":"<generated text>"}]}]}Query the catalogue with the same key and use an exact returned `id` in `model`.
curl https://api.sealarca.ch/v1/models \
-H "Authorization: Bearer $SEALARCA_API_KEY"{"data":[{"id":"<model-id>","object":"model"}]}The response is scoped to the key. Use an exact returned id as the model value; do not copy a model name from this page.
These statuses describe the published contract. Unavailable routes are intentionally not published.
/modelsDiscover model IDs visible to the key.
/responsesRecommended format for new OpenAI SDK integrations.
/chat/completionsMessages format for existing clients.
/messagesMessages format for Claude-compatible clients and integrations using the Messages API.
/embeddingsCreate vector representations for search and similarity.
/vault/proofs/{receiptId}Consult the status and checks associated with a Vault receipt.
/vault/proofs/{receiptId}/bundleDownload the signed JWS for a terminal Vault proof.
/vault/proofs/signing-keysRetrieve the public JWKS of active and retired keys.
/vault/attestation?nonce=…Request a fresh attestation bound to a client nonce.
Four examples: three use Responses and the fourth uses Messages. Select a model authorised for the relevant endpoint.
curl https://api.sealarca.ch/v1/responses \
-H "Authorization: Bearer $SEALARCA_API_KEY" \
-H "Content-Type: application/json" \
-d "{\"model\":\"$SEALARCA_MODEL_ID\",\"input\":\"Analyze this document and return three risks.\"}"Responses, Chat Completions and Claude Messages can request server-sent events with stream: true.
Set stream to true and use curl -N or an equivalent streaming HTTP client. The response uses text/event-stream.
Process data: records separated by blank lines. Event payloads and termination depend on the route contract; do not assume names beyond it.
curl -N https://api.sealarca.ch/v1/responses \
-H "Authorization: Bearer $SEALARCA_API_KEY" \
-H "Content-Type: application/json" \
-d "{\"model\":\"$SEALARCA_MODEL_ID\",\"input\":\"Summarize this file.\",\"stream\":true}"curl -N https://api.sealarca.ch/v1/messages \
-H "x-api-key: $SEALARCA_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d "{\"model\":\"$SEALARCA_MODEL_ID\",\"max_tokens\":256,\"stream\":true,\"messages\":[{\"role\":\"user\",\"content\":\"Summarize this file.\"}]}"Content-Type: text/event-stream
data: <JSON event>
A confidential multimodal route for text, images, tools and structured outputs, with streaming.
curl https://api.sealarca.ch/v1/responses \
-H "Authorization: Bearer $SEALARCA_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "glm.5.3-flash-shield",
"input": "Reply with OK.",
"reasoning": {
"effort": "low"
},
"store": false,
"max_output_tokens": 256
}'curl https://api.sealarca.ch/v1/chat/completions \
-H "Authorization: Bearer $SEALARCA_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "glm.5.3-flash-shield",
"messages": [
{
"role": "user",
"content": "Reply with OK."
}
],
"reasoning_effort": "low",
"max_tokens": 256,
"stream": true
}'curl https://api.sealarca.ch/v1/messages \
-H "Authorization: Bearer $SEALARCA_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "glm.5.3-flash-shield",
"max_tokens": 256,
"messages": [
{
"role": "user",
"content": "Reply with OK."
}
]
}'Read X-Sealarca-Receipt-ID and X-Sealarca-Receipt-URL from the response. The receipt becomes available after finalization and delivery; a 404 may be temporary. complete, interrupted and failed describe the observed exchange.
# X-Sealarca-Receipt-ID / X-Sealarca-Receipt-URL / X-Sealarca-Proof-Profile
curl https://api.sealarca.ch/v1/vault/proofs/$RECEIPT_ID/bundle \
-H "Authorization: Bearer $SEALARCA_API_KEY"
# JWKS: https://api.sealarca.ch/v1/vault/proofs/signing-keysEvery accepted Vault inference provides a receipt that links the response to the route and session verified by Sealarca.
Before forwarding any request for execution, Sealarca checks that the trust environment and channel associated with the route meet Vault requirements. If this check fails or is unavailable, the inference is refused without fallback to an unprotected route. The Vault receipt then links the response to the verified route and session.
curl -i https://api.sealarca.ch/v1/responses \
-H "Authorization: Bearer $SEALARCA_API_KEY" \
-H "Content-Type: application/json" \
-d "{\"model\":\"$SEALARCA_MODEL_ID\",\"input\":\"Summarize this file.\"}"The initial status is pending. Keep the receipt identifier and use the provided URL to consult the final verdict.
export SEALARCA_VAULT_PROOF_URL="<X-Sealarca-Vault-Proof-URL>"
curl "$SEALARCA_VAULT_PROOF_URL" \
-H "Authorization: Bearer $SEALARCA_API_KEY"{
"schema": "sealarca-vault-proof/1",
"receipt_id": "<receipt-id>",
"status": "verified",
"model": "<model-id>",
"created_at": "<ISO-8601>",
"updated_at": "<ISO-8601>",
"verified_at": "<ISO-8601>",
"expires_at": "<ISO-8601>",
"admission": {
"status": "verified",
"checked_at": "<ISO-8601>",
"attested_at": "<ISO-8601>",
"expires_at": "<ISO-8601>",
"evidence_digest": "sha256:<hex>",
"keyset_digest": "sha256:<hex>"
},
"checks": [
{ "id": "attestation", "status": "verified" },
{ "id": "receipt", "status": "verified" }
],
"hashes": {
"request": "sha256:<hex>",
"response": "sha256:<hex>",
"request_received": "sha256:<hex>",
"request_forwarded": "sha256:<hex>",
"response_returned": "sha256:<hex>",
"keyset": "sha256:<hex>",
"evidence": "sha256:<hex>",
"runtime": "sha256:<hex>"
}
}Verification is still in progress. Try again after a short delay.
Admission, the receipt, and the referenced Vault session satisfied the required checks.
The proof was not verified. Do not treat the result as verified.
404 means the proof is missing or inaccessible; 410 means it has expired.
503 · VAULT_VERIFICATION_UNAVAILABLEVault verification is unavailable. The inference is refused without falling back to unprotected execution.
The standard interface exposes the result of Sealarca’s verification. It is not a complete export of raw artifacts for independent cryptographic verification; access remains subject to the applicable contractual process.
Any active key belonging to the same user can consult their history. Never place an API key in the URL.
For streaming, the receipt is announced with the response; the final verdict becomes available after the stream ends.
Proofs are retained for 90 days and contain no prompt, response or API key.
Provide a unique nonce of 64 lowercase hexadecimal characters to request a fresh, authenticated attestation.
export SEALARCA_VAULT_NONCE="<64-lowercase-hex-characters>"
curl "https://api.sealarca.ch/v1/vault/attestation?nonce=$SEALARCA_VAULT_NONCE" \
-H "Authorization: Bearer $SEALARCA_API_KEY"The standard response contains status, nonce, verification and expiry times, normalized checks, evidence, runtime and keyset digests, and the useful environment-key fingerprints. Complete artifacts remain restricted to contractually authorized audit export.
{
"schema": "sealarca-vault-attestation/1",
"status": "verified",
"nonce": "<64-lowercase-hex-characters>",
"verified_at": "<ISO-8601>",
"expires_at": "<ISO-8601>",
"checks": [{ "id": "<check-id>", "status": "verified" }],
"measurements": {
"evidence": "sha256:<hex>",
"runtime": "sha256:<hex>",
"keyset": "sha256:<hex>"
},
"key_fingerprints": {
"receipt_signing": ["sha256:<hex>"],
"tls": ["sha256:<hex>"],
"e2ee": ["sha256:<hex>"]
}
}Each value is sha256: followed by the hexadecimal digest of the bytes observed in the Vault chain. request_received covers the body received by the environment, request_forwarded the body possibly transformed before the model, and response_returned the observed response bytes, including streams. After normalization or transformation, these bytes may differ from the client’s original HTTP bytes.
A terminal verified or failed proof is available as sealarca-vault-proof-bundle/1. Its payload is canonicalized under RFC 8785 and then signed as JWS with Ed25519. The public JWKS retains active and retired keys so an archived bundle can be checked after 90 days.
The signature guarantees the bundle’s integrity and Sealarca origin. It does not extend the attestation’s validity period and, by itself, is not an independent hardware verification.
curl -f "$SEALARCA_VAULT_PROOF_URL/bundle" \
-H "Authorization: Bearer $SEALARCA_API_KEY" \
-o sealarca-vault-proof.jws.json
curl -f "https://api.sealarca.ch/v1/vault/proofs/signing-keys" \
-o sealarca-vault-jwks.jsonimport { createHash, createPublicKey, verify } from "node:crypto";
import { readFileSync } from "node:fs";
const bundle = JSON.parse(readFileSync("sealarca-vault-proof.jws.json", "utf8"));
const jwks = JSON.parse(readFileSync("sealarca-vault-jwks.json", "utf8"));
const header = JSON.parse(Buffer.from(bundle.protected, "base64url"));
if (header.alg !== "EdDSA" || header.typ !== "sealarca-vault-proof+jws") throw new Error("Unexpected JWS algorithm");
const jwk = jwks.keys.find((key) => key.kid === header.kid);
if (!jwk || jwk.kty !== "OKP" || jwk.crv !== "Ed25519") throw new Error("Signing key not found or unsupported");
// Obtain this fingerprint independently from your current Sealarca contract/guide.
// Never trust a fingerprint received alongside an untrusted bundle.
const expected = process.env.SEALARCA_VAULT_JWK_SHA256;
if (!expected) throw new Error("Trusted JWK fingerprint required");
const thumbprint = createHash("sha256")
.update(JSON.stringify({ crv: jwk.crv, kty: jwk.kty, x: jwk.x }))
.digest("hex");
if ("sha256:" + thumbprint !== expected) throw new Error("Unexpected signing key");
const valid = verify(
null,
Buffer.from(bundle.protected + "." + bundle.payload),
createPublicKey({ key: jwk, format: "jwk" }),
Buffer.from(bundle.signature, "base64url"),
);
if (!valid) throw new Error("Invalid Vault proof signature");
console.log(JSON.parse(Buffer.from(bundle.payload, "base64url")));503 · VAULT_PROOF_SIGNING_UNAVAILABLEMinimal fields, output format, and streaming behavior for confirmed routes.
No request body. Bearer token required.
Key-scoped list containing the model IDs visible to that key.
model
input
max_output_tokens
stream
`response` object; SDKs expose `output_text`.
Required: `model` and `input`. Common documented fields: `max_output_tokens` (positive integer) and `stream` (boolean). Other fields are model-dependent and not part of this minimal contract.
export SEALARCA_API_KEY="YOUR_SEALARCA_API_KEY"
export SEALARCA_MODEL_ID="MODEL_ID_FROM_V1_MODELS"
curl https://api.sealarca.ch/v1/responses \
-H "Authorization: Bearer $SEALARCA_API_KEY" \
-H "Content-Type: application/json" \
-d "{\"model\":\"$SEALARCA_MODEL_ID\",\"input\":\"Summarize this confidential text in three points.\",\"max_output_tokens\":256}"model
messages
max_tokens
stream
choices[0].message.content
Required: `model` and `messages`. Common documented fields: `max_tokens` (positive integer) and `stream` (boolean). Other fields are model-dependent and not part of this minimal contract.
curl https://api.sealarca.ch/v1/chat/completions \
-H "Authorization: Bearer $SEALARCA_API_KEY" \
-H "Content-Type: application/json" \
-d "{\"model\":\"$SEALARCA_MODEL_ID\",\"messages\":[{\"role\":\"user\",\"content\":\"Summarize this file.\"}],\"max_tokens\":256}"model
messages
max_tokens
stream
content
Required: `model`, `max_tokens`, and `messages`. `stream` enables SSE events. Other fields depend on the published contract.
curl https://api.sealarca.ch/v1/messages \
-H "x-api-key: $SEALARCA_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d "{\"model\":\"$SEALARCA_MODEL_ID\",\"max_tokens\":256,\"messages\":[{\"role\":\"user\",\"content\":\"Summarize this file.\"}]}"Do not retry blindly. Fix deterministic 4xx errors and apply bounded backoff to temporary failures.
Request ID. Every `/v1/` contract response includes an `x-request-id` header generated by Sealarca. An error body may also include a separate `(id=…)` identifier; retain both when present.
These practices follow the current authentication, model access, billing, and request tracing behavior.
Load the API key from an environment variable or secret manager and rotate it if exposed.
Call /v1/models with the same key and avoid hardcoding a model ID in deployed code.
Correct deterministic 4xx errors. Use bounded backoff for 429, 5xx, and gateway timeouts.
Retain x-request-id and any error ID returned with a failure for support and diagnosis.
The API uses prepaid CHF credits. The balance is checked before a request and usage is charged from the actual call.
The balance is funded through credit top-ups.
Input and output may have different rates. The catalogue shows each model’s public prices.
Top up the balance before retrying.
Use these links for account access, model consumption, protections, and the technical service boundary.
Follow the account, credit, and API key setup journey.
See the live model catalogue and published consumption details.
Review protections, data handling, and their limits.
Understand the public service flow and protected execution environment.
Create access, discover a permitted model, and send your first server-side request.