API-DOKUMENTATION

Integrieren Sie Sealarca in Ihre Anwendung.

Authentifizieren Sie sich mit Ihrem Sealarca-API-Schlüssel, entdecken Sie die verfügbaren Modelle, senden Sie Responses-, Chat-Completions- oder Claude-Messages-Anfragen und verbinden Sie den Dienst mit Ihrer Software.

Jetzt starten Schnellstart ansehen

Die Beispiele verwenden eine von GET /v1/models zurückgegebene Modell-ID. In dieser Dokumentation ist kein Modell fest hinterlegt.

Erster Aufruf

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\":\"Fassen Sie diesen vertraulichen Text in drei Punkten zusammen.\",\"max_output_tokens\":256}"

Antwortstruktur

JSON · Gekürzte Antwort

{"id":"<response-id>","object":"response","status":"completed","model":"<model-id>","output":[{"type":"message","role":"assistant","content":[{"type":"output_text","text":"<generated text>"}]}]}

HIER BEGINNEN

Vom Konto zur ersten Antwort

Halten Sie diese Reihenfolge ein: Zugang, Modellentdeckung und anschliessend eine serverseitige Anfrage.

01
Konto erstellen
Erstellen Sie Ihr Sealarca-Konto für den Dashboard-Zugriff.
02
Guthaben hinzufügen
Laden Sie Ihr Prepaid-Guthaben in CHF auf, bevor Sie die API aufrufen.
03
API-Schlüssel erstellen
Erstellen Sie einen Sealarca-API-Schlüssel und bewahren Sie ihn auf dem Server auf.
04
Modelle auflisten
Rufen Sie GET /v1/models auf und wählen Sie eine für Ihren Schlüssel sichtbare ID.
05
Ersten Aufruf senden
Verwenden Sie die zurückgegebene ID mit Responses, Chat Completions oder Claude Messages.

Jede Anfrage authentifizieren

Die öffentliche API akzeptiert einen Sealarca-API-Schlüssel als Bearer-Token oder für Claude-Clients über `x-api-key` auf der Messages-Route.

Authentifizierungs-Header

Verwenden Sie `Authorization: Bearer ...` für Responses und Chat Completions. Claude-Clients können mit `anthropic-version` auf `/v1/messages` `x-api-key: ...` verwenden.

Authorization: Bearer $SEALARCA_API_KEYx-api-key: $SEALARCA_API_KEYanthropic-version: 2023-06-01

Schlüssel auf dem Server halten

Legen Sie ihn nie in eine öffentliche Webanwendung, eine verteilte mobile App, ein Repository oder eine NEXT_PUBLIC_*-Variable. Desk ist ein eigener lokaler Client: Der Benutzer gibt den Schlüssel ein und er bleibt nur während der Tab-Sitzung erhalten.

Erste Anfrage

Ein serverseitiger Schlüssel, die Basis-URL und ein JSON-Body genügen. Das kanonische Beispiel verwendet Responses.

Basis-URL: https://api.sealarca.ch/v1
Bearer-Token: Authorization: Bearer $SEALARCA_API_KEY
Content-Type: application/json

Ausschliesslich serverseitiger Schlüssel. Platzieren Sie den Schlüssel niemals in einer öffentlichen Webanwendung, einem Browser-Bundle, einer `NEXT_PUBLIC_*`-Variable, einem Git-Repository oder einer verteilten mobilen App. Eine öffentliche Webanwendung muss Ihr Backend aufrufen, das anschliessend Sealarca aufruft.

1. Responses konfigurieren und aufrufenbash

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\":\"Fassen Sie diesen vertraulichen Text in drei Punkten zusammen.\",\"max_output_tokens\":256}"

Minimal erwartete JSON-Antwort

Ein anderes Modell wählen

2. Antwort lesenjson

{"id":"<response-id>","object":"response","status":"completed","model":"<model-id>","output":[{"type":"message","role":"assistant","content":[{"type":"output_text","text":"<generated text>"}]}]}

Modelle ermitteln

Fragen Sie den Katalog mit demselben Schlüssel ab und verwenden Sie eine exakt zurückgegebene `id` im Feld `model`.

GET /v1/modelsbash

curl https://api.sealarca.ch/v1/models \
  -H "Authorization: Bearer $SEALARCA_API_KEY"

Gekürzte Antwortjson

{"data":[{"id":"<model-id>","object":"model"}]}

Die Antwort ist auf den Schlüssel begrenzt. Verwenden Sie eine exakt zurückgegebene ID als model-Wert und kopieren Sie keinen Modellnamen aus dieser Seite.

Modelle, Fähigkeiten und Preise vergleichen

Öffentlicher Endpunkt-Vertrag

Diese Statusangaben beschreiben den veröffentlichten Vertrag. Nicht verfügbare Routen werden bewusst nicht veröffentlicht.

Öffentliche Sealarca-Endpunkte
Methode	Endpunkt	Status	Streaming	Nutzung und Grenzen
GET	Models `/models`	Bestätigt	—	Modell-IDs ermitteln, die für den Schlüssel sichtbar sind. Schlüsselbezogene Antwort; das folgende Beispiel ist gekürzt.
POST	Responses `/responses`	Bestätigt	SSE	Empfohlenes Format für neue Integrationen mit dem OpenAI-SDK. Standardmässig wird JSON zurückgegeben; setzen Sie `stream: true`, um SSE anzufordern.
POST	Chat Completions `/chat/completions`	Bestätigt	SSE	Messages-Format für bestehende Clients. Standardmässig wird JSON zurückgegeben; setzen Sie `stream: true`, um SSE anzufordern.
POST	Claude Messages `/messages`	Bestätigt	SSE	Messages-Format für Claude-kompatible Clients und Integrationen mit der Messages API. Verwenden Sie die genaue von `/models` zurückgegebene ID. Die verfügbaren Fähigkeiten hängen vom veröffentlichten Modell ab.
POST	Embeddings `/embeddings`	Bestätigt	—	Vektordarstellungen für Suche und Ähnlichkeitsvergleich erstellen. Technischer Endpoint-Vertrag, sofern Ihr Katalog ein Embedding-Modell liefert. Im derzeit dokumentierten öffentlichen Katalog ist kein Embedding-Modell verfügbar. Kein Streaming.
GET	Vault-Nachweis `/vault/proofs/{receiptId}`	Bestätigt	—	Status und Prüfungen zu einem Vault-Beleg abrufen. Authentifizierung erforderlich; 202 für pending, 200 für das Ergebnis, 404 bei fehlendem oder unzulässigem Zugriff, 410 bei Ablauf.
GET	Signiertes Nachweis-Bundle `/vault/proofs/{receiptId}/bundle`	Bestätigt	—	Das signierte JWS eines endgültigen Vault-Nachweises herunterladen. Gleiche Benutzerisolation; 202 bei pending, 200 nach Signatur, 404 oder 410 je nach Fall, 503 wenn die Signatur nicht verfügbar ist.
GET	Vault-Signaturschlüssel `/vault/proofs/signing-keys`	Bestätigt	—	Das öffentliche JWKS der aktiven und zurückgezogenen Schlüssel abrufen. Öffentlich und ohne Authentifizierung; bewahren Sie den im Vertrag vorgesehenen Referenz-Fingerabdruck auf.
GET	Vault-Attestierung `/vault/attestation?nonce=…`	Bestätigt	—	Eine frische, an einen Client-Nonce gebundene Attestierung anfordern. Der Nonce muss genau 64 kleingeschriebene Hexadezimalzeichen enthalten.

GET

Models

/models

Bestätigt

Modell-IDs ermitteln, die für den Schlüssel sichtbar sind.

Streaming: —
Hinweis: Schlüsselbezogene Antwort; das folgende Beispiel ist gekürzt.

POST

Responses

/responses

Bestätigt

Empfohlenes Format für neue Integrationen mit dem OpenAI-SDK.

Streaming: SSE
Hinweis: Standardmässig wird JSON zurückgegeben; setzen Sie `stream: true`, um SSE anzufordern.

POST

Chat Completions

/chat/completions

Bestätigt

Messages-Format für bestehende Clients.

Streaming: SSE
Hinweis: Standardmässig wird JSON zurückgegeben; setzen Sie `stream: true`, um SSE anzufordern.

POST

Claude Messages

/messages

Bestätigt

Messages-Format für Claude-kompatible Clients und Integrationen mit der Messages API.

Streaming: SSE
Hinweis: Verwenden Sie die genaue von `/models` zurückgegebene ID. Die verfügbaren Fähigkeiten hängen vom veröffentlichten Modell ab.

POST

Embeddings

/embeddings

Bestätigt

Vektordarstellungen für Suche und Ähnlichkeitsvergleich erstellen.

Streaming: —
Hinweis: Technischer Endpoint-Vertrag, sofern Ihr Katalog ein Embedding-Modell liefert. Im derzeit dokumentierten öffentlichen Katalog ist kein Embedding-Modell verfügbar. Kein Streaming.

GET

Vault-Nachweis

/vault/proofs/{receiptId}

Bestätigt

Status und Prüfungen zu einem Vault-Beleg abrufen.

Streaming: —
Hinweis: Authentifizierung erforderlich; 202 für pending, 200 für das Ergebnis, 404 bei fehlendem oder unzulässigem Zugriff, 410 bei Ablauf.

GET

Signiertes Nachweis-Bundle

/vault/proofs/{receiptId}/bundle

Bestätigt

Das signierte JWS eines endgültigen Vault-Nachweises herunterladen.

Streaming: —
Hinweis: Gleiche Benutzerisolation; 202 bei pending, 200 nach Signatur, 404 oder 410 je nach Fall, 503 wenn die Signatur nicht verfügbar ist.

GET

Vault-Signaturschlüssel

/vault/proofs/signing-keys

Bestätigt

Das öffentliche JWKS der aktiven und zurückgezogenen Schlüssel abrufen.

Streaming: —
Hinweis: Öffentlich und ohne Authentifizierung; bewahren Sie den im Vertrag vorgesehenen Referenz-Fingerabdruck auf.

GET

Vault-Attestierung

/vault/attestation?nonce=…

Bestätigt

Eine frische, an einen Client-Nonce gebundene Attestierung anfordern.

Streaming: —
Hinweis: Der Nonce muss genau 64 kleingeschriebene Hexadezimalzeichen enthalten.

Sprachbeispiele

Vier Beispiele: Drei verwenden Responses, das vierte Messages. Wählen Sie ein für den jeweiligen Endpoint freigegebenes Modell.

cURLbash

curl https://api.sealarca.ch/v1/responses \
  -H "Authorization: Bearer $SEALARCA_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"model\":\"$SEALARCA_MODEL_ID\",\"input\":\"Analysieren Sie dieses Dokument und nennen Sie drei Risiken.\"}"

Eine Antwort streamen

Responses, Chat Completions und Claude Messages können mit stream: true Server-Sent Events anfordern.

Streaming aktivieren

Setzen Sie stream auf true und verwenden Sie curl -N oder einen gleichwertigen Streaming-HTTP-Client. Die Antwort verwendet text/event-stream.

Den Stream lesen

Verarbeiten Sie data:-Datensätze, die durch Leerzeilen getrennt sind. Ereignisdaten und Beendigung hängen vom Routenvertrag ab.

POST /v1/responses · stream=truebash

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\":\"Fassen Sie diese Datei zusammen.\",\"stream\":true}"

POST /v1/messages · stream=truebash

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\":\"Fassen Sie diese Datei zusammen.\"}]}"

Beispielhaftes Framingtext

Content-Type: text/event-stream

data: <JSON event>

GLM 5.3 Flash — Shield

Eine vertrauliche multimodale Route für Text, Bilder, Tools und strukturierte Ausgaben mit Streaming.

Shield verbindet eine geschützte Ausführungsumgebung mit einem von Sealarca signierten Beleg. Dieser dokumentiert den von unserem Gateway beobachteten Austausch.
Hashes beziehen sich auf JSON-Daten und SSE-Streams zwischen dem Sealarca-Gateway und dem Verschlüsselungsproxy vor der Antwortkonvertierung, nicht auf die ursprünglichen HTTP-Bytes des Clients. Manifest-Digests sind Umgebungsbeobachtungen ohne unabhängige Hardwarebindung an die Antwort.
Die Unterhaltung muss in jeder Anfrage enthalten sein. store=true, background, previous_response_id, conversation und cache_salt werden abgelehnt. Serverseitig ausgeführte Tools sind nicht verfügbar.
reasoning_effort akzeptiert low, high oder max. Standard ist low; Reasoning kann nicht deaktiviert werden. Reasoning-Tokens werden als Ausgabe-Tokens abgerechnet, auch wenn der Stream vor der Anzeige einer Antwort unterbrochen wird.
Modellkontext: bis zu 1 048 576 Tokens. Von Sealarca konfiguriertes Ausgabelimit: 131 072 Tokens pro Anfrage. Kontingente und tatsächliche Routenlimits können dieses Limit reduzieren. Responses wird in Chat Completions konvertiert. Vorschau-Route.
Signierte Belege und Metadaten werden 90 Tage aufbewahrt. Belege und Logs enthalten keine Prompts, Antworten oder Bilder. Gemeinsames Caching ist deaktiviert.

POST /v1/responsesbash

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
}'

POST /v1/chat/completionsbash

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
}'

POST /v1/messagesbash

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."
    }
  ]
}'

X-Sealarca-Receipt-ID und X-Sealarca-Receipt-URL aus der Antwort lesen. Der Beleg ist nach Abschluss und Übermittlung verfügbar; ein 404 kann vorübergehend sein. complete, interrupted und failed beschreiben den beobachteten Austausch.

Shield receiptbash

# 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-keys

Nachweis einer Vault-Inferenz abrufen

Jede akzeptierte Vault-Inferenz enthält einen Beleg, der die Antwort mit der von Sealarca geprüften Route und Sitzung verknüpft.

Prüfung vor jeder Ausführung

Vor jeder Weiterleitung zur Ausführung prüft Sealarca, ob die Vertrauensumgebung und der mit der Route verbundene Kanal die Vault-Anforderungen erfüllen. Schlägt diese Prüfung fehl oder ist sie nicht verfügbar, wird die Inferenz ohne Rückfall auf eine ungeschützte Route abgelehnt. Der Vault-Beleg verknüpft anschliessend die Antwort mit der geprüften Route und Sitzung.

Inferenz und Nachweis-Headerbash

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\":\"Fassen Sie diese Datei zusammen.\"}"

Drei Header aufbewahren

Der Anfangsstatus ist pending. Bewahren Sie die Belegkennung auf und rufen Sie das endgültige Ergebnis über die angegebene URL ab.

X-Sealarca-Vault-Receipt-ID
X-Sealarca-Vault-Proof-Status
X-Sealarca-Vault-Proof-URL

GET /v1/vault/proofs/{receiptId}bash

export SEALARCA_VAULT_PROOF_URL="<X-Sealarca-Vault-Proof-URL>"

curl "$SEALARCA_VAULT_PROOF_URL" \
  -H "Authorization: Bearer $SEALARCA_API_KEY"

sealarca-vault-proof/1json

{
  "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>"
  }
}

202 · pending

Die Prüfung läuft noch. Versuchen Sie es nach einer kurzen Wartezeit erneut.

200 · verified

Zulassung, Beleg und referenzierte Vault-Sitzung haben die erforderlichen Prüfungen erfüllt.

200 · failed

Der Nachweis wurde nicht bestätigt. Behandeln Sie das Ergebnis nicht als verifiziert.

404 / 410

404 bedeutet, dass der Nachweis fehlt oder nicht zugänglich ist; 410 bedeutet, dass er abgelaufen ist.

503 · VAULT_VERIFICATION_UNAVAILABLE

Die Vault-Prüfung ist nicht verfügbar. Die Inferenz wird abgelehnt, ohne auf eine ungeschützte Ausführung auszuweichen.

Die Standardschnittstelle zeigt das Ergebnis der Prüfung durch Sealarca. Sie ist kein vollständiger Export der Rohartefakte für eine unabhängige kryptografische Prüfung; der Zugang unterliegt dem anwendbaren vertraglichen Verfahren.

Jeder aktive Schlüssel desselben Benutzers kann dessen Verlauf abrufen. Platzieren Sie einen API-Schlüssel niemals in der URL.

Beim Streaming wird der Beleg mit der Antwort angekündigt; das endgültige Ergebnis ist nach dem Ende des Streams verfügbar.

Nachweise werden 90 Tage aufbewahrt und enthalten weder Prompt noch Antwort oder API-Schlüssel.

Erweiterte Prüfung der Vault-Umgebung

Geben Sie einen eindeutigen Nonce aus 64 kleingeschriebenen Hexadezimalzeichen an, um eine frische, authentifizierte Attestierung anzufordern.

GET /v1/vault/attestation?nonce=…bash

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"

Schema sealarca-vault-attestation/1

Die Standardantwort enthält Status, Nonce, Prüf- und Ablaufzeit, normalisierte Prüfungen, Evidence-, Runtime- und Keyset-Digests sowie die nützlichen Fingerabdrücke der Umgebungsschlüssel. Vollständige Artefakte bleiben dem vertraglich genehmigten Audit-Export vorbehalten.

sealarca-vault-attestation/1json

{
  "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>"]
  }
}

Definition der Hashes

Jeder Wert besteht aus sha256: gefolgt vom hexadezimalen Digest der in der Vault-Kette beobachteten Bytes. request_received umfasst den von der Umgebung empfangenen Body, request_forwarded den vor dem Modell eventuell transformierten Body und response_returned die beobachteten Antwortbytes einschliesslich Streams. Nach Normalisierung oder Transformation können diese Bytes von den ursprünglichen HTTP-Bytes des Clients abweichen.

Signiertes Bundle und Offline-Prüfung

Ein endgültiger Nachweis mit Status verified oder failed ist als sealarca-vault-proof-bundle/1 verfügbar. Sein Payload wird nach RFC 8785 kanonisiert und danach als JWS mit Ed25519 signiert. Das öffentliche JWKS bewahrt aktive und zurückgezogene Schlüssel auf, damit ein archiviertes Bundle nach 90 Tagen geprüft werden kann.

Die Signatur gewährleistet Integrität und Herkunft des Bundles von Sealarca. Sie verlängert nicht die Gültigkeitsdauer der Attestierung und ist für sich allein keine unabhängige Hardwareprüfung.

GET /v1/vault/proofs/{receiptId}/bundle · sealarca-vault-proof-bundle/1bash

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.json

Offline-Prüfung mit Ed25519 und Node.jsjavascript

import { 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_UNAVAILABLE

Endpunkt-Referenz

Minimale Felder, Ausgabeformat und Streaming-Verhalten für bestätigte Routen.

GET

/models

Bestätigt

Anfrage

Kein Request-Body. Bearer-Token erforderlich.

Antwort

Schlüsselbezogene Liste mit den für diesen Schlüssel sichtbaren Modell-IDs.

POST

/responses

Bestätigt

Erforderlich

model
input

Häufig

max_output_tokens
stream

Ausgabe

`response`-Objekt; SDKs exponieren `output_text`.

Erforderlich: `model` und `input`. Übliche dokumentierte Felder: `max_output_tokens` (positive Ganzzahl) und `stream` (Boolean). Andere Felder hängen vom Modell ab und gehören nicht zu diesem Mindestvertrag.

POST /v1/responsesbash

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\":\"Fassen Sie diesen vertraulichen Text in drei Punkten zusammen.\",\"max_output_tokens\":256}"

POST

/chat/completions

Bestätigt

Erforderlich

model
messages

Häufig

max_tokens
stream

Ausgabe

choices[0].message.content

Erforderlich: `model` und `messages`. Übliche dokumentierte Felder: `max_tokens` (positive Ganzzahl) und `stream` (Boolean). Andere Felder hängen vom Modell ab und gehören nicht zu diesem Mindestvertrag.

POST /v1/chat/completionsbash

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\":\"Fassen Sie diese Datei zusammen.\"}],\"max_tokens\":256}"

POST

/messages

Bestätigt

Erforderlich

model
messages

Häufig

max_tokens
stream

Ausgabe

content

Erforderlich: `model`, `max_tokens` und `messages`. `stream` aktiviert SSE-Ereignisse. Andere Felder hängen vom veröffentlichten Vertrag ab.

POST /v1/messagesbash

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\":\"Fassen Sie diese Datei zusammen.\"}]}"

Fehler und Wiederholungsregeln

Wiederholen Sie Anfragen nicht blind. Beheben Sie deterministische 4xx-Fehler und wenden Sie begrenzten Backoff bei vorübergehenden Fehlern an.

Fehlercodes und Wiederholungsregeln
HTTP	Ursache	Empfohlene Massnahme	Wiederholen	Retry-After
400	Ungültiges JSON, fehlendes Feld oder nicht unterstützter Parameter.	Korrigieren Sie die Anfrage vor einem erneuten Versuch.	Nein, nicht unverändert	—
401	Fehlendes, ungültiges oder widerrufenes Bearer-Token.	Prüfen und ersetzen Sie den Schlüssel.	Nein, nicht ohne neuen Schlüssel	—
402	Unzureichendes Guthaben.	Laden Sie Guthaben im Dashboard auf.	Nach Aufladung	—
403	Der API-Schlüssel darf die angeforderte Route oder das Modell nicht verwenden.	Prüfen Sie die Berechtigung und verwenden Sie eine für diesen Schlüssel zurückgegebene Modell-ID.	Nein, nicht ohne Berechtigungen oder Anfrage zu ändern.	—
404	Unbekannte öffentliche Route oder Modell-ID; Modellverfügbarkeit kann auch als 503 gemeldet werden.	Lesen Sie `/models` erneut, prüfen Sie den Pfad und korrigieren Sie Modell oder Route vor dem nächsten Versuch.	Nein, nicht unverändert	—
408	Das Gateway hat vor Abschluss der Anfrage das Zeitlimit erreicht.	Reduzieren Sie die Eingabe- oder Ausgabegrösse und wiederholen Sie mit begrenztem Backoff.	Ja, begrenzt	Falls vorhanden
409	Die Anfrage ist vorübergehend nicht verfügbar.	Warten Sie kurz und wiederholen Sie die Anfrage mit begrenztem Backoff.	Ja, begrenzt	Falls vorhanden
422	Ein Anfrageparameter ist für das ausgewählte Modell ungültig.	Prüfen Sie die dokumentierten Felder und korrigieren Sie die Anfrage.	Nein, nicht unverändert	—
429	Ratenbegrenzung oder vorübergehende Kapazitätsgrenze erreicht.	Gleichzeitige Anfragen reduzieren und Backoff anwenden.	Ja	Beachten, falls vorhanden
500	Interner Fehler des Sealarca-Dienstes.	Mit begrenztem Backoff wiederholen und Request- oder Fehler-ID aufbewahren.	Ja, begrenzt	—
502	Ungültige Antwort der Route.	Mit begrenztem Backoff wiederholen.	Ja	Falls vorhanden
503	Ausgewähltes Modell vorübergehend nicht verfügbar.	Mit Obergrenze wiederholen und bei Bedarf ein anderes Modell verwenden.	Ja	Falls vorhanden
504	Das Gateway hat vor Abschluss der Anfrage das Zeitlimit erreicht.	Reduzieren Sie die Eingabe- oder Ausgabegrösse und wiederholen Sie mit begrenztem Backoff.	Ja, begrenzt	Falls vorhanden

400

Ursache: Ungültiges JSON, fehlendes Feld oder nicht unterstützter Parameter.
Aktion: Korrigieren Sie die Anfrage vor einem erneuten Versuch.
Wiederholen: Nein, nicht unverändert
Retry-After: —

401

Ursache: Fehlendes, ungültiges oder widerrufenes Bearer-Token.
Aktion: Prüfen und ersetzen Sie den Schlüssel.
Wiederholen: Nein, nicht ohne neuen Schlüssel
Retry-After: —

402

Ursache: Unzureichendes Guthaben.
Aktion: Laden Sie Guthaben im Dashboard auf.
Wiederholen: Nach Aufladung
Retry-After: —

403

Ursache: Der API-Schlüssel darf die angeforderte Route oder das Modell nicht verwenden.
Aktion: Prüfen Sie die Berechtigung und verwenden Sie eine für diesen Schlüssel zurückgegebene Modell-ID.
Wiederholen: Nein, nicht ohne Berechtigungen oder Anfrage zu ändern.
Retry-After: —

404

Ursache: Unbekannte öffentliche Route oder Modell-ID; Modellverfügbarkeit kann auch als 503 gemeldet werden.
Aktion: Lesen Sie `/models` erneut, prüfen Sie den Pfad und korrigieren Sie Modell oder Route vor dem nächsten Versuch.
Wiederholen: Nein, nicht unverändert
Retry-After: —

408

Ursache: Das Gateway hat vor Abschluss der Anfrage das Zeitlimit erreicht.
Aktion: Reduzieren Sie die Eingabe- oder Ausgabegrösse und wiederholen Sie mit begrenztem Backoff.
Wiederholen: Ja, begrenzt
Retry-After: Falls vorhanden

409

Ursache: Die Anfrage ist vorübergehend nicht verfügbar.
Aktion: Warten Sie kurz und wiederholen Sie die Anfrage mit begrenztem Backoff.
Wiederholen: Ja, begrenzt
Retry-After: Falls vorhanden

422

Ursache: Ein Anfrageparameter ist für das ausgewählte Modell ungültig.
Aktion: Prüfen Sie die dokumentierten Felder und korrigieren Sie die Anfrage.
Wiederholen: Nein, nicht unverändert
Retry-After: —

429

Ursache: Ratenbegrenzung oder vorübergehende Kapazitätsgrenze erreicht.
Aktion: Gleichzeitige Anfragen reduzieren und Backoff anwenden.
Wiederholen: Ja
Retry-After: Beachten, falls vorhanden

500

Ursache: Interner Fehler des Sealarca-Dienstes.
Aktion: Mit begrenztem Backoff wiederholen und Request- oder Fehler-ID aufbewahren.
Wiederholen: Ja, begrenzt
Retry-After: —

502

Ursache: Ungültige Antwort der Route.
Aktion: Mit begrenztem Backoff wiederholen.
Wiederholen: Ja
Retry-After: Falls vorhanden

503

Ursache: Ausgewähltes Modell vorübergehend nicht verfügbar.
Aktion: Mit Obergrenze wiederholen und bei Bedarf ein anderes Modell verwenden.
Wiederholen: Ja
Retry-After: Falls vorhanden

504

Ursache: Das Gateway hat vor Abschluss der Anfrage das Zeitlimit erreicht.
Aktion: Reduzieren Sie die Eingabe- oder Ausgabegrösse und wiederholen Sie mit begrenztem Backoff.
Wiederholen: Ja, begrenzt
Retry-After: Falls vorhanden

Anfrage-ID. Jede `/v1/`-Antwort enthält einen von Sealarca generierten `x-request-id`-Header. Ein Fehlerkörper kann zusätzlich eine separate Kennung `(id=…)` enthalten; bewahren Sie beide auf, falls vorhanden.

Bewährte Vorgehensweisen

Diese Empfehlungen folgen dem aktuellen Verhalten von Authentifizierung, Modellzugriff, Abrechnung und Anfrageverfolgung.

Geheimnis schützen
Laden Sie den Schlüssel aus einer Umgebungsvariable oder einem Secret-Manager und rotieren Sie ihn bei einer Offenlegung.
Modell-IDs entdecken
Rufen Sie /v1/models mit demselben Schlüssel auf und hinterlegen Sie keine Modell-ID fest im bereitgestellten Code.
Selektiv wiederholen
Korrigieren Sie deterministische 4xx-Fehler. Verwenden Sie begrenztes Backoff für 429, 5xx und Gateway-Timeouts.
Anfrage-IDs behalten
Bewahren Sie x-request-id und eine mit dem Fehler gelieferte Fehler-ID für Support und Diagnose auf.

`store` und Aufbewahrung Der öffentliche Vertrag definiert `store` nicht als Kontrolle der Datenspeicherung. Verlassen Sie sich nicht auf `store: false` anstelle der Sealarca-Garantien für fehlende Inhaltsprotokollierung und fehlenden Antwort-Cache; operative Metadaten unterliegen weiterhin den geltenden Bedingungen.

Guthaben und Limits

Die API verwendet Prepaid-Guthaben in CHF. Das Guthaben wird vor der Anfrage geprüft und die tatsächliche Nutzung belastet.

Kein Pflichtabonnement

Das Guthaben wird über Guthabenaufladungen finanziert.

Kosten pro Modell

Input und Output können unterschiedliche Tarife haben. Der Katalog zeigt die öffentlichen Preise jedes Modells.

HTTP 402

Laden Sie das Guthaben vor einem erneuten Versuch auf.

Modelle und Preise anzeigen

Mit der passenden Sealarca-Seite fortfahren

Nutzen Sie diese Links für Kontozugang, Modellverbrauch, Schutzmassnahmen und den technischen Umfang des Dienstes.

Bereit, Sealarca zu integrieren?

Erstellen Sie Ihren Zugang, entdecken Sie ein erlaubtes Modell und senden Sie Ihre erste serverseitige Anfrage.

Jetzt starten Preise ansehen

Integrieren Sie Sealarca in Ihre Anwendung.

Vom Konto zur ersten Antwort

Konto erstellen

Guthaben hinzufügen

API-Schlüssel erstellen

Modelle auflisten

Ersten Aufruf senden

Jede Anfrage authentifizieren

Erste Anfrage

Minimal erwartete JSON-Antwort

Modelle ermitteln

Öffentlicher Endpunkt-Vertrag

Models

Responses

Chat Completions

Claude Messages

Embeddings

Vault-Nachweis

Signiertes Nachweis-Bundle

Vault-Signaturschlüssel

Vault-Attestierung

Sprachbeispiele

Eine Antwort streamen

Streaming aktivieren

Den Stream lesen

GLM 5.3 Flash — Shield

Nachweis einer Vault-Inferenz abrufen

Prüfung vor jeder Ausführung

Drei Header aufbewahren

202 · pending

200 · verified

200 · failed

404 / 410

Erweiterte Prüfung der Vault-Umgebung

Schema sealarca-vault-attestation/1

Definition der Hashes

Signiertes Bundle und Offline-Prüfung

Endpunkt-Referenz

/models

Anfrage

Antwort

/responses

Erforderlich

Häufig

Ausgabe

/chat/completions

Erforderlich

Häufig

Ausgabe

/messages

Erforderlich

Häufig

Ausgabe

Fehler und Wiederholungsregeln

Bewährte Vorgehensweisen

Geheimnis schützen

Modell-IDs entdecken

Selektiv wiederholen

Anfrage-IDs behalten

Guthaben und Limits

Kein Pflichtabonnement

Kosten pro Modell

HTTP 402

Mit der passenden Sealarca-Seite fortfahren

Schlüssel erstellen

Preise ansehen

Sicherheit und Datenschutz lesen

Infrastruktur lesen

Bereit, Sealarca zu integrieren?