Streaming.

Une session de streaming garde un vrai navigateur ouvert sur un workflow et le rend appelable : rejouez une tranche des étapes enregistrées comme handler, exposez des fonctions de script, ou pointez un client OpenAI dessus et laissez le modèle appeler les deux comme outils — ancré dans la page en direct.

modèle ▸ les couches

Une session, trois couches.

Une session de streaming démarre depuis un workflow. Ses étapes enregistrées se scindent à une frontière de mise en place : la tranche de mise en place s’exécute une fois au démarrage — naviguer, se connecter, arriver — et les étapes restantes deviennent la matière des handlers, la surface appelable de la session en direct. Un script avancé optionnel ajoute vos propres fonctions par-dessus.

handlers ▸ la surface appelable

Handlers.

Un handler est une unité nommée et appelable sur une session en direct. Sa définition porte ces champs :

POST /api/streaming/sessions/{session_key}/handlers
{
  "name": "search_orders",
  "type": "steps",
  "step_range": [4, 9],
  "input_variables": ["order_id"],
  "extract_fields": ["order_status", "order_total"]
}

script ▸ vos propres fonctions

Le script avancé.

Un workflow peut porter une étape advanced_script. Son script est injecté dans la session en direct, et les fonctions qu’il déclare rejoignent la liste des handlers vue par les appelants — même surface d’invocation, même exposition en outils :

{
  "type": "advanced_script",
  "config": {
    "code": "…",
    "persistent": true,
    "functions": ["summarize_thread"]
  }
}

invoke ▸ appeler un handler

Invoquer, et modifier les handlers en direct.

Appelez un handler par son nom sur une session en cours. Le corps de la requête a deux champs :

POST /api/streaming/sessions/{session_key}/invoke/search_orders
{ "data": { "order_id": "A-1042" }, "timeout": 30 }

# Manage handlers on the running session:
POST   /api/streaming/sessions/{session_key}/handlers
DELETE /api/streaming/sessions/{session_key}/handlers/{handler_name}

Les handlers ne sont pas figés au démarrage : POST …/handlers avec une définition de handler en ajoute un à la session en cours, et DELETE …/handlers/{handler_name} le retire.

openai ▸ surface prête à l’emploi

La surface compatible OpenAI.

Les SDK OpenAI et frameworks d’agents existants pilotent une session sans client sur mesure. Les messages reçoivent leur réponse depuis la session en direct — ce que le navigateur montre réellement — et les handlers et fonctions de script de la session apparaissent comme des outils que le modèle peut appeler :

from openai import OpenAI

client = OpenAI(
    base_url="https://api.usewrit.app/api/streaming/workflows/{workflow_id}/v1",
    api_key="wt_YOUR_KEY",
)

r = client.chat.completions.create(
    model="streaming",
    messages=[{"role": "user", "content": "What does order A-1042's page say?"}],
)
print(r.choices[0].message.content)

Les trois mêmes endpoints existent sous deux bases : /api/streaming/workflows/{workflow_id}/v1 (une session est démarrée pour vous depuis le workflow) et /api/streaming/sessions/{session_key}/v1 (vous adressez une session déjà démarrée).

sessions ▸ démarrage et options

Démarrer une session.

Une requête de démarrage de session prend :

session_persistence : l’état de connexion sauvegardé (cookies et localStorage) peut être restauré dans une nouvelle session, pour que la mise en place ne rejoue pas une connexion que le navigateur détient déjà.

POST /api/streaming/sessions/start
GET  /api/streaming/sessions
POST /api/streaming/sessions/{session_key}/end
POST /api/streaming/sessions/{session_key}/invoke/{handler_name}
GET  /api/streaming/sessions/{session_key}/events        # SSE
WS   /api/streaming/sessions/{session_key}/ws

# OpenAI-compatible, at both bases:
POST /api/streaming/workflows/{workflow_id}/v1/chat/completions
POST /api/streaming/workflows/{workflow_id}/v1/responses
GET  /api/streaming/workflows/{workflow_id}/v1/models
#    …and the same three under /api/streaming/sessions/{session_key}/v1/

Une session rapporte queued, starting, running, ending, ended ou failed ; à sa fin, end_reason vaut user_ended, timeout, agent_lost ou error.

exemple ▸ un portail de support

Exemple travaillé : un portail de support, appelable.

Une session, les deux couches, puis la surface OpenAI par-dessus :

1. La session démarre depuis le workflow du portail de support. La tranche de mise en place se connecte avec l’état de persona sauvegardé et arrive sur la vue des commandes — une seule fois.
2. Un handler nommé search_orders (type « steps ») rejoue la tranche de recherche enregistrée via son step_range, prend input_variables ["order_id"], et renvoie des extract_fields comme le statut et le total de la commande.
3. Le script avancé déclare summarize_thread — une fonction qui lit le fil de support ouvert directement sur la page. Elle rejoint la liste des handlers à côté de search_orders.
4. Un client OpenAI pointé sur la session voit les deux comme outils. En pleine conversation, le modèle appelle search_orders avec un numéro de commande, puis summarize_thread — chaque réponse ancrée dans ce que le portail montre réellement.

tarif ▸ sans frais par appel

Aucun frais par appel.

Les appels chat, responses et invoke sont sans frais par appel : ils injectent votre message dans la page du navigateur en direct de la session — aucun modèle de la plateforme ne s’interpose, il n’y a donc rien à facturer par appel. Seul le temps de navigateur de la session est réglé à sa fin.

suite ▸ où aller

Continuez.

• Workflows — les étapes enregistrées que rejouent la mise en place et les handlers d’une session.
• sessions IA — les exécutions guidées par un objectif, et l’assistant qui écrit votre script avancé.
• Facturation & utilisation — comment le temps de navigateur est réglé à la fin de la session.