DOCUMENTATION API

Intégrez Sealarca à votre application.

Authentifiez-vous avec votre clé API Sealarca, récupérez les modèles accessibles à cette clé, envoyez des requêtes Responses, Chat Completions ou Claude Messages et reliez le service à votre logiciel.

Commencer Voir le quickstart

Les exemples utilisent un model ID retourné par GET /v1/models. Aucun modèle n’est figé dans cette documentation.

Premier appel

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\":\"Résume ce texte confidentiel en trois points.\",\"max_output_tokens\":256}"

Structure de réponse

JSON · Réponse abrégée

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

POUR COMMENCER

Du compte à la première réponse

Suivez cet ordre : accès, découverte des modèles, puis requête côté serveur.

01
Créer un compte
Créez votre compte Sealarca pour accéder au dashboard.
02
Ajouter des crédits
Rechargez votre solde prépayé en CHF avant d’appeler l’API.
03
Créer une clé API
Créez une clé API Sealarca et conservez-la côté serveur.
04
Lister les modèles
Appelez GET /v1/models et choisissez un ID visible par votre clé.
05
Faire le premier appel
Utilisez l’ID retourné avec Responses, Chat Completions ou Claude Messages.

Authentifier chaque requête

L’API publique accepte une clé API Sealarca comme Bearer token ou, pour les clients Claude, via `x-api-key` sur la route Messages.

En-têtes d’authentification

Utilisez `Authorization: Bearer ...` pour Responses et Chat Completions. Les clients Claude peuvent utiliser `x-api-key: ...` avec `anthropic-version` sur `/v1/messages`.

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

Conserver la clé côté serveur

Ne l’exposez jamais dans une application web publique, une application mobile distribuée, un dépôt ou une variable NEXT_PUBLIC_*. Desk est un client local distinct : l’utilisateur y fournit sa clé, conservée uniquement pendant la session de l’onglet.

Première requête

Une clé serveur, la base URL et un corps JSON suffisent. L’exemple canonique utilise Responses.

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

Clé côté serveur uniquement. Ne placez jamais la clé dans une application web publique, un bundle navigateur, une variable `NEXT_PUBLIC_*`, un dépôt Git ou une application mobile distribuée. Une application web publique doit appeler votre backend, qui appelle ensuite Sealarca.

1. Configurer et appeler 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\":\"Résume ce texte confidentiel en trois points.\",\"max_output_tokens\":256}"

Réponse JSON minimale attendue

Choisir un autre modèle

2. Lire la réponsejson

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

Découvrir les modèles

Interrogez le catalogue avec la même clé et utilisez exactement un `id` retourné dans `model`.

GET /v1/modelsbash

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

Réponse abrégéejson

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

La réponse est limitée par la clé. Utilisez un id retourné exactement comme valeur de model ; ne copiez pas un nom de modèle depuis cette page.

Comparer les modèles, capacités et prix

Contrat des endpoints publics

Ces statuts décrivent le contrat publié. Les routes non disponibles ne sont volontairement pas publiées.

Endpoints publics Sealarca
Méthode	Endpoint	Statut	Streaming	Usage et limites
GET	Models `/models`	Confirmé	—	Découvrir les model IDs visibles par la clé. Réponse limitée à la clé ; l’exemple ci-dessous est abrégé.
POST	Responses `/responses`	Confirmé	SSE	Format recommandé pour les nouvelles intégrations OpenAI SDK. Le JSON est renvoyé par défaut ; définissez `stream: true` pour demander du SSE.
POST	Chat Completions `/chat/completions`	Confirmé	SSE	Format messages pour clients existants. Le JSON est renvoyé par défaut ; définissez `stream: true` pour demander du SSE.
POST	Claude Messages `/messages`	Confirmé	SSE	Format Messages pour les clients compatibles Claude et les intégrations qui utilisent l’API Messages. Utilisez l’identifiant exact renvoyé par `/models`. Les fonctionnalités disponibles dépendent du modèle publié.
POST	Embeddings `/embeddings`	Confirmé	—	Créer des représentations vectorielles pour la recherche et la similarité. Contrat technique disponible, sous réserve d’un modèle de type Embedding retourné par votre catalogue. Aucun modèle d’embeddings n’est proposé dans le catalogue public actuellement documenté. Pas de streaming.
GET	Preuve Vault `/vault/proofs/{receiptId}`	Confirmé	—	Consulter l’état et les contrôles associés à un reçu Vault. Authentification requise ; 202 pour pending, 200 pour le verdict, 404 si absent ou non autorisé, 410 si expiré.
GET	Bundle de preuve signé `/vault/proofs/{receiptId}/bundle`	Confirmé	—	Télécharger le JWS signé d’une preuve Vault terminale. Même isolation utilisateur ; 202 si pending, 200 si signé, 404 ou 410 selon le cas, 503 si la signature est indisponible.
GET	Clés de signature Vault `/vault/proofs/signing-keys`	Confirmé	—	Obtenir le JWKS public des clés actives et retirées. Public et sans authentification ; conservez l’empreinte de référence prévue par votre contrat.
GET	Attestation Vault `/vault/attestation?nonce=…`	Confirmé	—	Demander une attestation fraîche liée à un nonce client. Le nonce doit contenir exactement 64 caractères hexadécimaux minuscules.

GET

Models

/models

Confirmé

Découvrir les model IDs visibles par la clé.

Streaming: —
Note: Réponse limitée à la clé ; l’exemple ci-dessous est abrégé.

POST

Responses

/responses

Confirmé

Format recommandé pour les nouvelles intégrations OpenAI SDK.

Streaming: SSE
Note: Le JSON est renvoyé par défaut ; définissez `stream: true` pour demander du SSE.

POST

Chat Completions

/chat/completions

Confirmé

Format messages pour clients existants.

Streaming: SSE
Note: Le JSON est renvoyé par défaut ; définissez `stream: true` pour demander du SSE.

POST

Claude Messages

/messages

Confirmé

Format Messages pour les clients compatibles Claude et les intégrations qui utilisent l’API Messages.

Streaming: SSE
Note: Utilisez l’identifiant exact renvoyé par `/models`. Les fonctionnalités disponibles dépendent du modèle publié.

POST

Embeddings

/embeddings

Confirmé

Créer des représentations vectorielles pour la recherche et la similarité.

Streaming: —
Note: Contrat technique disponible, sous réserve d’un modèle de type Embedding retourné par votre catalogue. Aucun modèle d’embeddings n’est proposé dans le catalogue public actuellement documenté. Pas de streaming.

GET

Preuve Vault

/vault/proofs/{receiptId}

Confirmé

Consulter l’état et les contrôles associés à un reçu Vault.

Streaming: —
Note: Authentification requise ; 202 pour pending, 200 pour le verdict, 404 si absent ou non autorisé, 410 si expiré.

GET

Bundle de preuve signé

/vault/proofs/{receiptId}/bundle

Confirmé

Télécharger le JWS signé d’une preuve Vault terminale.

Streaming: —
Note: Même isolation utilisateur ; 202 si pending, 200 si signé, 404 ou 410 selon le cas, 503 si la signature est indisponible.

GET

Clés de signature Vault

/vault/proofs/signing-keys

Confirmé

Obtenir le JWKS public des clés actives et retirées.

Streaming: —
Note: Public et sans authentification ; conservez l’empreinte de référence prévue par votre contrat.

GET

Attestation Vault

/vault/attestation?nonce=…

Confirmé

Demander une attestation fraîche liée à un nonce client.

Streaming: —
Note: Le nonce doit contenir exactement 64 caractères hexadécimaux minuscules.

Exemples par langage

Quatre exemples : trois utilisent Responses et le quatrième utilise Messages. Choisissez un modèle autorisé pour l’endpoint concerné.

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\":\"Analyse ce document et retourne trois risques.\"}"

Diffuser une réponse

Responses, Chat Completions et Claude Messages peuvent demander des événements envoyés par le serveur avec stream: true.

Activer le streaming

Définissez stream à true et utilisez curl -N ou un client HTTP équivalent. La réponse utilise text/event-stream.

Lire le flux

Traitez les enregistrements data: séparés par des lignes vides. Les charges utiles et la terminaison dépendent du contrat de la route.

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\":\"Résume ce dossier.\",\"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\":\"Résume ce dossier.\"}]}"

Framing illustratiftext

Content-Type: text/event-stream

data: <JSON event>

GLM 5.3 Flash — Shield

Une route confidentielle multimodale pour le texte, les images, les outils et les sorties structurées, avec streaming.

Shield associe un environnement d’exécution protégé à un reçu signé par Sealarca. Ce reçu documente l’échange observé par notre passerelle.
Les hashes portent sur les corps JSON et les flux SSE entre la passerelle Sealarca et le proxy de chiffrement, avant les conversions de réponse. Ils ne désignent pas les octets HTTP originaux du client. Les digests des manifestes sont des observations du déploiement, sans liaison matérielle indépendante avec la réponse.
Envoyer la conversation dans chaque requête. store=true, background, previous_response_id, conversation et cache_salt sont refusés. Les outils exécutés côté serveur ne sont pas disponibles.
reasoning_effort accepte low, high ou max. Le réglage par défaut est low ; le raisonnement ne peut pas être désactivé. Les tokens de raisonnement sont facturés comme tokens de sortie, y compris si le flux est interrompu avant l’affichage d’une réponse.
Contexte maximal du modèle : 1 048 576 tokens. Plafond de sortie configuré par Sealarca : 131 072 tokens par requête. Les quotas et limites effectives de la route peuvent réduire ce plafond. Responses est converti vers Chat Completions. Route en aperçu.
Les reçus signés et métadonnées sont conservés 90 jours. Aucun prompt, réponse ou image n’est conservé dans les reçus ou les journaux. Le cache partagé est désactivé.

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

Lire X-Sealarca-Receipt-ID et X-Sealarca-Receipt-URL sur la réponse. Le reçu devient disponible après finalisation et livraison ; un 404 peut être temporaire. Les états complete, interrupted et failed décrivent l’échange observé.

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

Consulter la preuve d’une inférence Vault

Chaque inférence Vault acceptée fournit un reçu qui relie la réponse à la route et à la session vérifiées par Sealarca.

Contrôle avant toute exécution

Avant toute transmission pour exécution, Sealarca contrôle que l’environnement de confiance et le canal associés à la route satisfont aux exigences Vault. Si ce contrôle échoue ou n’est pas disponible, l’inférence est refusée sans fallback vers une route non protégée. Le reçu Vault relie ensuite la réponse à la route et à la session vérifiées.

Inférence et en-têtes de preuvebash

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\":\"Résume ce dossier.\"}"

Trois en-têtes à conserver

Le statut initial est pending. Conservez l’identifiant du reçu et utilisez l’URL fournie pour consulter le verdict final.

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

La vérification est encore en cours. Réessayez après un court délai.

200 · verified

L’admission, le reçu et la session Vault référencée ont satisfait aux contrôles exigés.

200 · failed

La preuve n’a pas été validée. Ne considérez pas le résultat comme vérifié.

404 / 410

404 signifie que la preuve est absente ou inaccessible ; 410 signifie qu’elle a expiré.

503 · VAULT_VERIFICATION_UNAVAILABLE

La vérification Vault n’est pas disponible. L’inférence est refusée sans basculer vers une exécution non protégée.

L’interface standard expose le résultat de la vérification opérée par Sealarca. Elle ne constitue pas l’export intégral des artefacts bruts pour une vérification cryptographique indépendante ; leur accès reste soumis au processus contractuel applicable.

Toute clé active du même utilisateur peut consulter son historique. Ne placez jamais une clé API dans l’URL.

En streaming, le reçu est annoncé avec la réponse ; le verdict définitif devient disponible après la fin du flux.

Les preuves sont conservées 90 jours et ne contiennent ni prompt, ni réponse, ni clé API.

Contrôle avancé de l’environnement Vault

Fournissez un nonce unique de 64 caractères hexadécimaux minuscules pour demander une attestation fraîche et authentifiée.

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"

Schéma sealarca-vault-attestation/1

La réponse standard contient le statut, le nonce, les dates de vérification et d’expiration, les contrôles normalisés, les digests d’évidence, de runtime et de keyset, ainsi que les empreintes des clés d’environnement utiles. Les artefacts complets restent réservés à l’export d’audit contractuellement autorisé.

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

Définition des hashes

Chaque valeur est sha256: suivie du digest hexadécimal des octets observés dans la chaîne Vault. request_received couvre le corps reçu par l’environnement, request_forwarded le corps éventuellement transformé avant le modèle, et response_returned les octets de réponse observés, flux compris. Après normalisation ou transformation, ces octets peuvent différer des octets HTTP originaux du client.

Bundle signé et vérification hors ligne

Une preuve terminale verified ou failed est disponible sous sealarca-vault-proof-bundle/1. Son payload est canonisé selon RFC 8785 puis signé en JWS avec Ed25519. Le JWKS public conserve les clés actives et retirées pour vérifier un bundle archivé après 90 jours.

La signature garantit l’intégrité et l’origine Sealarca du bundle. Elle ne prolonge pas la validité temporelle de l’attestation et ne constitue pas, à elle seule, une vérification matérielle indépendante.

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

Vérification Ed25519 hors ligne avec 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

Référence des endpoints

Champs minimaux, format de sortie et comportement de streaming des routes confirmées.

GET

/models

Confirmé

Requête

Aucun corps. Bearer token requis.

Réponse

Liste limitée par la clé contenant les model IDs visibles pour cette clé.

POST

/responses

Confirmé

Requis

model
input

Courants

max_output_tokens
stream

Sortie

Objet `response`; les SDK exposent `output_text`.

Requis : `model` et `input`. Champs courants documentés : `max_output_tokens` (entier positif) et `stream` (booléen). Les autres champs dépendent du modèle et ne font pas partie de ce contrat minimal.

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\":\"Résume ce texte confidentiel en trois points.\",\"max_output_tokens\":256}"

POST

/chat/completions

Confirmé

Requis

model
messages

Courants

max_tokens
stream

Sortie

choices[0].message.content

Requis : `model` et `messages`. Champs courants documentés : `max_tokens` (entier positif) et `stream` (booléen). Les autres champs dépendent du modèle et ne font pas partie de ce contrat minimal.

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\":\"Résume ce dossier.\"}],\"max_tokens\":256}"

POST

/messages

Confirmé

Requis

model
messages

Courants

max_tokens
stream

Sortie

content

Requis : `model`, `max_tokens` et `messages`. `stream` active les événements SSE. Les autres champs dépendent du contrat publié.

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\":\"Résume ce dossier.\"}]}"

Erreurs et règles de retry

Ne réessayez pas aveuglément. Corrigez les 4xx déterministes et appliquez un backoff borné aux erreurs temporaires.

Codes d’erreur et règles de retry
HTTP	Cause	Action recommandée	Retry	Retry-After
400	JSON invalide, champ absent ou paramètre non supporté.	Corriger la requête avant de réessayer.	Non, sans modification	—
401	Bearer token absent, invalide ou révoqué.	Vérifier puis remplacer la clé.	Non, sans nouvelle clé	—
402	Solde de crédits insuffisant.	Recharger les crédits dans le dashboard.	Après recharge	—
403	La clé API n’est pas autorisée à utiliser cette route ou ce modèle.	Vérifier les droits et utiliser un model ID retourné pour cette clé.	Non, sans modifier les droits ou la requête.	—
404	Route publique ou model ID inconnu ; l’indisponibilité du modèle peut aussi renvoyer 503.	Relire `/models`, vérifier le chemin et corriger le modèle ou la route avant de réessayer.	Non, sans correction	—
408	La passerelle a expiré avant la fin de la requête.	Réduire la taille de l’entrée ou de la sortie, puis réessayer avec un backoff borné.	Oui, limité	Lorsqu’il est présent
409	La requête est temporairement indisponible.	Attendre brièvement, puis réessayer avec un backoff borné.	Oui, limité	Lorsqu’il est présent
422	Un paramètre de requête est invalide pour le modèle sélectionné.	Vérifier les champs documentés et corriger la requête.	Non, sans modification	—
429	Limite de débit ou capacité temporaire atteinte.	Réduire la concurrence et appliquer un backoff.	Oui	Respecter le header s’il est présent
500	Erreur interne du service Sealarca.	Réessayer avec un backoff borné et conserver l’ID de requête ou d’erreur.	Oui, limité	—
502	Réponse invalide de la route.	Réessayer avec un backoff borné.	Oui	S’il est présent
503	Modèle sélectionné temporairement indisponible.	Réessayer avec un plafond et utiliser un autre modèle si nécessaire.	Oui	S’il est présent
504	La passerelle a expiré avant la fin de la requête.	Réduire la taille de l’entrée ou de la sortie, puis réessayer avec un backoff borné.	Oui, limité	Lorsqu’il est présent

400

Cause: JSON invalide, champ absent ou paramètre non supporté.
Action: Corriger la requête avant de réessayer.
Retry: Non, sans modification
Retry-After: —

401

Cause: Bearer token absent, invalide ou révoqué.
Action: Vérifier puis remplacer la clé.
Retry: Non, sans nouvelle clé
Retry-After: —

402

Cause: Solde de crédits insuffisant.
Action: Recharger les crédits dans le dashboard.
Retry: Après recharge
Retry-After: —

403

Cause: La clé API n’est pas autorisée à utiliser cette route ou ce modèle.
Action: Vérifier les droits et utiliser un model ID retourné pour cette clé.
Retry: Non, sans modifier les droits ou la requête.
Retry-After: —

404

Cause: Route publique ou model ID inconnu ; l’indisponibilité du modèle peut aussi renvoyer 503.
Action: Relire `/models`, vérifier le chemin et corriger le modèle ou la route avant de réessayer.
Retry: Non, sans correction
Retry-After: —

408

Cause: La passerelle a expiré avant la fin de la requête.
Action: Réduire la taille de l’entrée ou de la sortie, puis réessayer avec un backoff borné.
Retry: Oui, limité
Retry-After: Lorsqu’il est présent

409

Cause: La requête est temporairement indisponible.
Action: Attendre brièvement, puis réessayer avec un backoff borné.
Retry: Oui, limité
Retry-After: Lorsqu’il est présent

422

Cause: Un paramètre de requête est invalide pour le modèle sélectionné.
Action: Vérifier les champs documentés et corriger la requête.
Retry: Non, sans modification
Retry-After: —

429

Cause: Limite de débit ou capacité temporaire atteinte.
Action: Réduire la concurrence et appliquer un backoff.
Retry: Oui
Retry-After: Respecter le header s’il est présent

500

Cause: Erreur interne du service Sealarca.
Action: Réessayer avec un backoff borné et conserver l’ID de requête ou d’erreur.
Retry: Oui, limité
Retry-After: —

502

Cause: Réponse invalide de la route.
Action: Réessayer avec un backoff borné.
Retry: Oui
Retry-After: S’il est présent

503

Cause: Modèle sélectionné temporairement indisponible.
Action: Réessayer avec un plafond et utiliser un autre modèle si nécessaire.
Retry: Oui
Retry-After: S’il est présent

504

Cause: La passerelle a expiré avant la fin de la requête.
Action: Réduire la taille de l’entrée ou de la sortie, puis réessayer avec un backoff borné.
Retry: Oui, limité
Retry-After: Lorsqu’il est présent

Request ID. Chaque réponse du contrat `/v1/` inclut un header `x-request-id` généré par Sealarca. Le corps d’erreur peut aussi contenir un identifiant distinct `(id=…)` ; conservez les deux lorsqu’ils sont présents.

Bonnes pratiques opérationnelles

Ces recommandations suivent le comportement actuel de l’authentification, de l’accès aux modèles, de la facturation et du suivi des requêtes.

Protéger le secret
Chargez la clé depuis une variable d’environnement ou un gestionnaire de secrets et faites-la tourner si elle est exposée.
Découvrir les model IDs
Appelez /v1/models avec la même clé et évitez de figer un model ID dans le code déployé.
Réessayer avec discernement
Corrigez les erreurs 4xx déterministes. Utilisez un backoff borné pour 429, 5xx et les timeouts de passerelle.
Conserver les IDs de requête
Conservez x-request-id et tout identifiant d’erreur renvoyé avec un échec pour le support et le diagnostic.

`store` et conservation Le contrat public ne définit pas `store` comme un contrôle de conservation. Ne pas utiliser `store: false` à la place des garanties Sealarca d’absence de journalisation du contenu et de cache de réponses ; les métadonnées opérationnelles restent soumises aux conditions applicables.

Crédits et limites

L’API utilise des crédits prépayés en CHF. Le solde est contrôlé avant la requête et l’usage est débité sur l’appel réel.

Pas d’abonnement requis

Le solde est alimenté par des recharges de crédits.

Coût par modèle

L’entrée et la sortie peuvent avoir des tarifs distincts. Le catalogue affiche les prix publics par modèle.

HTTP 402

Rechargez le solde avant de réessayer.

Voir les modèles et les prix

Poursuivre avec la bonne page Sealarca

Utilisez ces liens pour l’accès au compte, la consommation des modèles, les protections et le périmètre technique du service.

Prêt à intégrer Sealarca ?

Créez votre accès, découvrez un modèle autorisé et envoyez votre première requête côté serveur.

Commencer Voir les tarifs

Intégrez Sealarca à votre application.

Du compte à la première réponse

Créer un compte

Ajouter des crédits

Créer une clé API

Lister les modèles

Faire le premier appel

Authentifier chaque requête

Première requête

Réponse JSON minimale attendue

Découvrir les modèles

Contrat des endpoints publics

Models

Responses

Chat Completions

Claude Messages

Embeddings

Preuve Vault

Bundle de preuve signé

Clés de signature Vault

Attestation Vault

Exemples par langage

Diffuser une réponse

Activer le streaming

Lire le flux

GLM 5.3 Flash — Shield

Consulter la preuve d’une inférence Vault

Contrôle avant toute exécution

Trois en-têtes à conserver

202 · pending

200 · verified

200 · failed

404 / 410

Contrôle avancé de l’environnement Vault

Schéma sealarca-vault-attestation/1

Définition des hashes

Bundle signé et vérification hors ligne

Référence des endpoints

/models

Requête

Réponse

/responses

Requis

Courants

Sortie

/chat/completions

Requis

Courants

Sortie

/messages

Requis

Courants

Sortie

Erreurs et règles de retry

Bonnes pratiques opérationnelles

Protéger le secret

Découvrir les model IDs

Réessayer avec discernement

Conserver les IDs de requête

Crédits et limites

Pas d’abonnement requis

Coût par modèle

HTTP 402

Poursuivre avec la bonne page Sealarca

Créer votre clé

Voir les tarifs

Lire sécurité et confidentialité

Lire l’infrastructure

Prêt à intégrer Sealarca ?