Streaming.

Una sesión de streaming mantiene un navegador real abierto sobre un workflow y lo hace invocable: reproduce una porción de los pasos grabados como handler, expón funciones de script, o apunta un cliente OpenAI y deja que el modelo llame a ambos como herramientas — anclado en la página en vivo.

modelo ▸ las capas

Una sesión, tres capas.

Una sesión de streaming arranca desde un workflow. Sus pasos grabados se dividen en una frontera de preparación: la porción de preparación corre una vez al iniciar — navegar, iniciar sesión, llegar — y los pasos restantes se vuelven material para los handlers, la superficie invocable de la sesión en vivo. Un script avanzado opcional añade funciones propias encima.

handlers ▸ la superficie invocable

Handlers.

Un handler es una unidad con nombre e invocable sobre una sesión en vivo. Su definición lleva estos campos:

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 ▸ tus propias funciones

El script avanzado.

Un workflow puede llevar un paso advanced_script. Su script se inyecta en la sesión en vivo, y las funciones que declara se suman a la lista de handlers que ven los llamadores — misma superficie de invocación, misma exposición como herramientas:

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

invoke ▸ llamar a un handler

Invocar, y cambiar handlers en vivo.

Llama a un handler por su nombre en una sesión en marcha. El cuerpo de la petición tiene dos campos:

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}

Los handlers no quedan congelados al iniciar: POST …/handlers con una definición de handler añade uno a la sesión en marcha, y DELETE …/handlers/{handler_name} lo quita.

openai ▸ superficie lista para usar

La superficie compatible con OpenAI.

Los SDK de OpenAI y frameworks de agentes existentes conducen una sesión sin cliente a medida. Los mensajes se responden desde la sesión en vivo — lo que el navegador muestra de verdad — y los handlers y funciones de script de la sesión aparecen como herramientas que el modelo puede llamar:

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)

Los mismos tres endpoints existen en dos bases: /api/streaming/workflows/{workflow_id}/v1 (se inicia una sesión por ti desde el workflow) y /api/streaming/sessions/{session_key}/v1 (te diriges a una sesión ya iniciada).

sesiones ▸ inicio y opciones

Iniciar una sesión.

Una petición de inicio de sesión toma:

session_persistence: el estado de sesión guardado (cookies y localStorage) puede restaurarse en una sesión nueva, para que la preparación no repita un inicio de sesión que el navegador ya tiene.

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/

Una sesión informa queued, starting, running, ending, ended o failed; al terminar, end_reason es user_ended, timeout, agent_lost o error.

ejemplo ▸ un portal de soporte

Ejemplo resuelto: un portal de soporte, invocable.

Una sesión, las dos capas, y la superficie OpenAI encima:

1. La sesión arranca desde el workflow del portal de soporte. La porción de preparación inicia sesión con el estado de persona guardado y aterriza en la vista de pedidos — una sola vez.
2. Un handler llamado search_orders (tipo "steps") reproduce la porción de búsqueda grabada mediante su step_range, toma input_variables ["order_id"] y devuelve extract_fields como el estado y el total del pedido.
3. El script avanzado declara summarize_thread — una función que lee el hilo de soporte abierto directamente de la página. Se suma a la lista de handlers junto a search_orders.
4. Un cliente OpenAI apuntado a la sesión ve ambos como herramientas. En plena conversación, el modelo llama a search_orders con un número de pedido y luego a summarize_thread — cada respuesta anclada en lo que el portal muestra de verdad.

precio ▸ sin cargo por llamada

Sin cargo por llamada.

Las llamadas chat, responses e invoke no tienen cargo por llamada: inyectan tu mensaje en la página del navegador en vivo de la sesión — ningún modelo de la plataforma se interpone, así que no hay nada que medir por llamada. Solo el tiempo de navegador de la sesión se liquida al terminar.

siguiente ▸ a dónde ir

Sigue adelante.

• Workflows — los pasos grabados que reproducen la preparación y los handlers de una sesión.
• AI sessions — las ejecuciones guiadas por objetivo, y el ayudante que escribe tu script avanzado.
• Facturación y uso — cómo se liquida el tiempo de navegador al terminar la sesión.