Documentación técnica. Todo lo que tu equipo necesita.

Cómo se conecta BIOS a tu software, cómo verificas la identidad de tus usuarios y qué límites y garantías tienes. Escrito para tu equipo técnico.

S1 · Empieza aquí

Introducción

Qué es BIOS para el dueño de un software, cómo se conecta y el vocabulario que verás en el resto de la documentación.

BIOS es la infraestructura que fabrica y opera agentes de IA sobre tu software. Se conecta a tu producto a través de su API (nunca por pantalla ni RPA), genera las herramientas que lo operan, y los agentes atienden a tu equipo, a los negocios que usan tu software y a sus clientes finales — siempre con la identidad y los permisos del usuario real.

Arquitectura

Todo el tráfico sale de BIOS hacia ti

El runtime de BIOS está alojado por la plataforma y hace llamadas HTTPS salientes a la URL base de tu API. Tú no instalas nada: solo expones tu API y un endpoint de identidad (el auth-bridge). La lista de IPs de salida está publicada para que restrinjas tu firewall.

Sin lock-in

Estándares abiertos

Las herramientas generadas se empaquetan como un servidor MCP estándar y la superficie de tu backend se describe en OpenAPI 3.1. Sin cajas negras.

Multi-tenant

Aislado por diseño

Cada partner es un tenant aislado a nivel de base de datos. Tus datos, tus clientes y tus credenciales nunca se cruzan con los de otro partner.

Glosario

Término	Qué es
Product	Tu software conectado a BIOS (su código, su API, su manual).
Assistant	Un agente configurado: rol, tono, instrucciones y automatizaciones.
Environment	Un entorno de tu software (producción, staging…) con su URL base y credenciales.
Deployment	La combinación asistente × producto × entorno que se publica y atiende.
Tool / Skill	Una operación de tu API convertida en herramienta · un flujo completo de tu frontend.
Auth-bridge	El webhook firmado que implementas para resolver la identidad de cada usuario final.
Verification Key	El secreto compartido con el que se firma cada llamada al auth-bridge.
Contract test	La validación automática que debe pasar una tool antes de publicarse.

S2 · Conexión

Onboarding e ingesta

Tres formas de conectar tu software y qué ocurre desde que conectas hasta que el agente está listo.

OpenAPI

Especificación de tu API

Sube el archivo o apunta a la URL de tu especificación (hasta 10 MB). Es la vía más directa si ya documentas tu API.

Git

Repositorio con OAuth

Conecta GitHub, GitLab o Bitbucket con OAuth. BIOS lee el código, extrae la superficie de tu API y queda enganchado a tus releases.

ZIP

Código empaquetado

¿Sin repo accesible? Sube el código en un ZIP de hasta 100 MB. El frontend puede ir por la misma vía, y el manual en PDF, DOCX, MD o HTML.

Qué pasa al conectar: el flujo de 3 agentes

Análisis en paralelo

Un agente lee tu frontend y redacta el manual de usuario; otro lee tu backend y genera la especificación OpenAPI de tu API real.

Referencia cruzada

Se cruzan las dos vistas: cada función de negocio de la interfaz queda ligada a los endpoints que la ejecutan. Los huecos se detectan y se reintentan.

Fabricación y verificación

Un tercer agente genera las tools y skills. Cada unidad pasa una verificación espejada (un ejecutor y un verificador independiente) y el gate final de contract tests antes de publicarse.

Resultado: un catálogo de tools y skills versionado, un manual de usuario y un manual técnico — generados desde tu código real, no desde suposiciones.

S3 · Identidad

Auth-bridge

La pieza clave: tus usuarios no hacen OAuth. Tu sistema expone un webhook firmado y BIOS actúa con la identidad y los permisos de cada usuario, mensaje a mensaje.

En cada mensaje de un usuario final, BIOS llama a un único endpoint que tú implementas. Tu sistema resuelve quién es (por su teléfono, email o usuario del canal) y devuelve un token por turno con sus permisos. No se cachean tokens y no hay OAuth de por medio.

La petición que recibes

POST /bios/auth-bridge HTTP/1.1
Content-Type: application/json
User-Agent: NordixBIOS-Runtime/1
X-BIOS-Timestamp: 1785851520
X-BIOS-Nonce: 9b2f7c1e-4c9a-4b7e-9d3f-2f8a1c6e5d40
X-BIOS-Key-Id: vk_2
X-BIOS-Delivery: dl_01J9…
X-BIOS-Signature: v1=3f1a9c…e2

{
  "version": "1",
  "deploymentId": "dep_9f2c…",
  "channel": "whatsapp",
  "channelUserId": "+34 612 345 678",
  "identifierType": "phone",
  "requestedAt": "2026-07-28T10:12:00Z",
  "context": { "messageId": "wamid.HBg…", "locale": "es" }
}

Verificar la firma (HMAC v1)

La cadena a firmar es timestamp \n nonce \n "POST" \n path \n sha256(body), firmada con tu Verification Key. Rechaza peticiones fuera de la ventana de ±300 s y nonces repetidos (caché ≥ 5 min). Compara siempre en tiempo constante.

import crypto from "node:crypto";

export function verifyBiosSignature(headers, rawBody, verificationKey, path) {
  const ts = headers["x-bios-timestamp"];
  const nonce = headers["x-bios-nonce"];
  const sig = (headers["x-bios-signature"] || "").replace(/^v1=/, "");
  if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false;  // ±300 s
  const bodyHash = crypto.createHash("sha256").update(rawBody).digest("hex");
  const signingString = [ts, nonce, "POST", path, bodyHash].join("\n");
  const expected = crypto
    .createHmac("sha256", verificationKey)
    .update(signingString)
    .digest("hex");
  return crypto.timingSafeEqual(Buffer.from(sig, "hex"), Buffer.from(expected, "hex"));
}

import hashlib, hmac, time

def verify_bios_signature(headers, raw_body: bytes, verification_key: str, path: str) -> bool:
    ts = headers["X-BIOS-Timestamp"]
    nonce = headers["X-BIOS-Nonce"]
    sig = headers["X-BIOS-Signature"].removeprefix("v1=")
    if abs(time.time() - float(ts)) > 300:          # ±300 s
        return False
    body_hash = hashlib.sha256(raw_body).hexdigest()
    signing_string = "\n".join([ts, nonce, "POST", path, body_hash])
    expected = hmac.new(verification_key.encode(), signing_string.encode(),
                        hashlib.sha256).hexdigest()
    return hmac.compare_digest(sig, expected)

function verify_bios_signature(array $headers, string $rawBody,
                                string $key, string $path): bool {
    $ts = $headers['X-BIOS-Timestamp'];
    $nonce = $headers['X-BIOS-Nonce'];
    $sig = str_replace('v1=', '', $headers['X-BIOS-Signature']);
    if (abs(time() - (int)$ts) > 300) return false;      // ±300 s
    $signing = implode("\n", [$ts, $nonce, 'POST', $path, hash('sha256', $rawBody)]);
    $expected = hash_hmac('sha256', $signing, $key);
    return hash_equals($expected, $sig);
}

# Petición firmada de prueba (ilustrativa, para test local)
BODY='{"version":"1","deploymentId":"dep_9f2c","channel":"web","channelUserId":"u1","identifierType":"username","requestedAt":"2026-07-28T10:12:00Z"}'
TS=$(date +%s); NONCE=$(uuidgen)
HASH=$(printf '%s' "$BODY" | shasum -a 256 | cut -d' ' -f1)
SIGNING=$(printf '%s\n%s\nPOST\n/bios/auth-bridge\n%s' "$TS" "$NONCE" "$HASH")
SIG=$(printf '%s' "$SIGNING" | openssl dgst -sha256 -hmac "{{VERIFICATION_KEY}}" -hex | sed 's/^.* //')

curl -X POST https://tu-api.example.com/bios/auth-bridge \
  -H "Content-Type: application/json" \
  -H "X-BIOS-Timestamp: $TS" -H "X-BIOS-Nonce: $NONCE" \
  -H "X-BIOS-Signature: v1=$SIG" \
  -d "$BODY"

Tu respuesta

Devuelve ok con una o varias cuentas, o unknown_user / blocked. Los ids que declares se inyectan automáticamente en los parámetros de identidad de cada tool — el modelo nunca puede falsearlos.

{
  "status": "ok",
  "accounts": [{
    "key": "default",
    "token": "usr_4821_t",
    "tokenType": "bearer",
    "user": { "id": "u_4821", "displayName": "Carmen", "locale": "es-ES" },
    "scopes": ["bookings:rw"],
    "ids": [{ "name": "customer_id", "value": "4821" }]
  }]
}

// status: "ok" | "unknown_user" | "blocked"

Generador de código + Pull Request

No hace falta que lo escribas tú: BIOS detecta tu framework y genera el endpoint completo (verificador + handler + .env.example, con el secreto siempre por variable de entorno). Y si quieres, abre el PR en tu repositorio en la rama nordixbios/auth-bridge-v{N} — nunca escribe en tu rama base.

# 1 · Genera el bundle (verifier + handler + .env.example) — 202, ejecución en curso
curl -X POST {{API_BASE}}/v1/assistants/{aid}/deployments/{did}/auth-bridge/generate \
  -H "X-API-Key: {{API_KEY}}" -H "Idempotency-Key: 7f3a1c9e"

# 2 · Revisa el código generado
curl {{API_BASE}}/v1/assistants/{aid}/deployments/{did}/auth-bridge/generated-code \
  -H "X-API-Key: {{API_KEY}}"

# 3 · Abre el Pull Request en tu repositorio
curl -X POST {{API_BASE}}/v1/assistants/{aid}/deployments/{did}/auth-bridge/commit \
  -H "X-API-Key: {{API_KEY}}" -H "Content-Type: application/json" \
  -d '{"confirm": true}'
# → { "prUrl": "https://github.com/tu-org/tu-repo/pull/128",
#     "branch": "nordixbios/auth-bridge-v3" }

Lenguaje	Frameworks detectados
Node.js	NestJS · Fastify · Koa · Express
PHP	Laravel · Symfony · Slim
Python	Django · FastAPI · Flask
Go	Gin · Echo · Chi · Fiber
Ruby / C# / Java	Rails · ASP.NET · Spring

Rotación de claves sin cortes: durante la ventana de rotación conviven la clave antigua y la nueva; la cabecera X-BIOS-Key-Id te dice cuál se usó en cada llamada, y el historial queda auditado. Errores del PR: 409 si la conexión Git no tiene permisos de escritura · 502 si tu proveedor Git falla.

S4 · Catálogo

Tools, skills y ciclo de vida

Cómo se generan, verifican, versionan y mantienen las herramientas — incluida la reacción automática a cada release de tu software.

Generación

Cada operación, una tool

Crear una reserva, emitir una factura, mover stock: cada operación de tu API se convierte en una tool con su esquema, su versión y su tasa de éxito medida en producción.

Contract tests

Lo que no pasa, no se publica

Antes de publicar, cada tool pasa un contract test: re-handshake contra tu auth-bridge y validación estricta contra la OpenAPI. En rojo, no sale.

Rollback

Volver atrás en un clic

Cada cambio queda versionado con su diff. Si algo falla tras una actualización, rollback automático a la última versión verificada — tus refinamientos no se pierden.

Ediciones

Ajusta sin miedo

Edita una tool a mano o con IA: la coherencia se valida siempre, y las que marques como protegidas no se tocan en las regeneraciones.

Releases: el ciclo autónomo

Detección

Un push a tu repositorio dispara el webhook (firmado por proveedor); además hay un sondeo de respaldo cada 10 minutos.

Diff incremental

BIOS analiza qué cambió y regenera solo lo afectado — pantallas, funciones y tools ligadas al cambio. Lo que desaparece de tu código, se retira del catálogo.

Verificación y publicación

Se repiten los contract tests. Verde: se publica. Rojo: rollback automático y aviso.

Eventos que recibirás (webhooks y panel): sync_completed · sync_failed · sync_rollback · user_linked · operation_failed · cost_limit · credit_exhausted. La política de sync puede ser automática o manual por deployment.

S5 · Canales

Canales

Siete canales incluidos, conectados por entorno. Qué necesitas aportar en cada uno.

Cada canal se conecta a un entorno concreto (producción, staging…), con unicidad por asistente + entorno + tipo. Las credenciales se cifran en reposo y en los listados solo se muestran enmascaradas.

Canal	Cómo se conecta	Qué aportas
WhatsApp	API oficial de Meta (Cloud API)	`phoneNumberId` + `accessToken`, o alta guiada con OAuth (Embedded Signup)
Telegram	Bot API	Token del bot (de @BotFather)
Microsoft Teams	Bot Framework (OAuth)	`appId` + `tenantId` + `clientSecret`
Slack	Events API (OAuth)	Instalación OAuth → `botToken`
Messenger · Instagram	OAuth de página de Meta	`pageAccessToken` + `appSecret`
Widget web	Script embebible	Dominios permitidos; el snippet se genera desde el panel
Email	3 modos	Buzón gestionado por BIOS · tu IMAP/SMTP · OAuth (Gmail / Microsoft)

El widget web

<!-- Un snippet por asistente; solo funciona en los dominios permitidos -->
<script src="{{WIDGET_BASE}}/widget.js" async
  data-config='{
    "widgetId": "{{WIDGET_ID}}",
    "theme": "auto",
    "position": "bottom-right"
  }'></script>

Los agentes leen y generan adjuntos, muestran indicador de escritura, mantienen memoria por usuario y escalan a un humano cuando toca — en todos los canales. El playground del panel te deja probar cualquier canal simulado antes de publicar.

S6 · API

API REST y webhooks salientes

Automatiza BIOS desde tu propio software: claves de API con scopes, idempotencia y webhooks firmados hacia tu sistema.

Autenticación y uso

Crea claves de API desde el panel con scope read (lecturas) o write (escrituras). Se envían en la cabecera X-API-Key. El secreto solo se muestra al crear o al revelar — y cada revelación queda auditada.

curl "{{API_BASE}}/v1/assistants?page=1&perPage=20" \
  -H "X-API-Key: {{API_KEY}}"

# Escrituras: añade Idempotency-Key para reintentos seguros (ventana 24 h)
curl -X POST "{{API_BASE}}/v1/…" \
  -H "X-API-Key: {{API_KEY}}" \
  -H "Idempotency-Key: 2b9d4f7a" \
  -d '{ … }'

const res = await fetch(`${API_BASE}/v1/assistants?page=1&perPage=20`, {
  headers: { "X-API-Key": process.env.BIOS_API_KEY },
});
if (res.status === 429) {
  const retryAfter = Number(res.headers.get("Retry-After") || 1);
  // espera y reintenta
}
const { data } = await res.json();

import os, requests

res = requests.get(
    f"{API_BASE}/v1/assistants",
    params={"page": 1, "perPage": 20},
    headers={"X-API-Key": os.environ["BIOS_API_KEY"]},
)
res.raise_for_status()
data = res.json()["data"]

Rate limit

600 req/min por clave

Con cabeceras RateLimit-Limit / Remaining / Reset y Retry-After en el 429. Sube el límite con tu acuerdo.

Idempotencia

Reintentos sin sustos

Añade Idempotency-Key a cualquier escritura: mismo body dentro de 24 h → misma respuesta; body distinto → 409.

Paginación

Predecible

page ≥ 1 y perPage entre 1 y 100 (20 por defecto) en todos los listados.

Webhooks hacia tu sistema

Suscríbete a eventos (sync_completed, sync_failed, user_linked, operation_failed…) y recíbelos firmados con el mismo esquema HMAC v1 del auth-bridge: verifica con el mismo código. Entrega at-least-once — deduplica por X-BIOS-Delivery. Desde el panel puedes probar el endpoint, rotar el secreto y reenviar cualquier entrega.

S7 · Límites

Límites y cuotas

Todos los límites técnicos en una tabla, para dimensionar tu integración sin sorpresas.

Concepto	Límite
Turnos del agente por conversación	8 turnos · 60 s por turno
Código fuente (ZIP)	hasta 100 MB
OpenAPI (URL o archivo)	hasta 10 MB
Documentos del manual	PDF · DOCX · MD · HTML
Rate limit de claves de API	600 req/min (ampliable por acuerdo)
Ventana de idempotencia	24 h por `Idempotency-Key`
Paginación	1–100 por página (20 por defecto)
Anti-replay del auth-bridge	±300 s · nonce de un solo uso (caché ≥ 5 min)
Detección de releases	webhook de push + sondeo cada 10 min
Webhooks salientes	at-least-once · dedup por `X-BIOS-Delivery`

Los límites de consumo (mensajes, usuarios activos, tokens) dependen de tu acuerdo y se controlan desde el panel de Billing, con techos de gasto y alertas que defines tú.

S8 · Seguridad

Seguridad y cumplimiento

Aislamiento multi-tenant, cifrado, residencia de datos en España y una identidad que el modelo no puede falsear.

Aislamiento

RLS forzado en base de datos

Row-Level Security activo y forzado en las tablas de tenant: el identificador de partner sale siempre del token, nunca de la petición. Un recurso de otro tenant simplemente no existe (404).

Cifrado

AES-256-GCM en aplicación

Credenciales y secretos cifrados con AES-256-GCM a nivel de aplicación antes de tocar la base de datos; en los listados solo viajan versiones enmascaradas y cada revelación queda auditada.

Residencia de datos

España (UE)

Datos y base de datos en la región eu-south-2 (Zaragoza); el correo transaccional sale desde eu-north-1 (Estocolmo). Todo dentro de la UE.

Identidad no falseable

Parámetros solo del auth-bridge

Los parámetros de identidad de cada tool se inyectan desde la respuesta verificada de tu auth-bridge: el modelo no puede inventarse un customer_id.

Anti-SSRF

Triple barrera de salida

Validación de URL pública (metadata de nube bloqueada), allowlist de destinos y guardia de redirecciones entre hosts en el ejecutor de tools.

Acceso

RBAC + MFA

Roles owner / admin / member / billing / viewer, doble factor, sesiones revocables y refresh token opaco en cookie httpOnly.

La lista de IPs de salida de BIOS está publicada en el estado público de la plataforma para que restrinjas tu auth-bridge y tu API por firewall.

S9 · Referencia

Referencia

El contrato de errores, los dominios de la API y cómo evolucionan.

Envelope de error

Todos los errores comparten el mismo formato — guarda siempre el requestId para soporte:

{
  "error": {
    "code": "RATE_LIMITED",
    "message": "Too many requests",
    "details": { "limitPerMin": 600 },
    "requestId": "req_01J9…"
  }
}

Código	Cuándo
`400`	Body inválido o campos obligatorios ausentes
`401`	Firma o credencial inválida / caducada
`404`	Recurso inexistente — también si pertenece a otro tenant
`409`	Conflicto: Idempotency-Key reutilizada con otro body · PR sin permisos de escritura
`422`	Validación de esquema fallida
`429`	`RATE_LIMITED` — respeta `Retry-After`

Dominios de la API

Más de 200 endpoints bajo /v1, organizados por dominios: assistants (productos, fuentes, deployments, auth-bridge, tools & skills, ejecuciones), channels, users finales, schedules, billing, keys & webhooks y notifications. La especificación OpenAPI completa, con ejemplos por lenguaje, se entrega con tu alta.

/v1 es estable: los cambios son aditivos. Los cambios con ruptura se anunciarán con antelación y convivirán con la versión anterior.

¿Dudas técnicas? Las resolvemos en una llamada.

Agenda una reunión

Technical documentation. Everything your team needs.

How BIOS connects to your software, how you verify your users' identity, and the limits and guarantees you get. Written for your technical team.

S1 · Start here

Introduction

What BIOS is for a software owner, how it connects, and the vocabulary used across these docs.

BIOS is the infrastructure that builds and operates AI agents on top of your software. It connects to your product through its API (never screen-scraping or RPA), generates the tools that operate it, and the agents serve your team, the businesses using your software and their end customers — always with the real user's identity and permissions.

Architecture

All traffic flows from BIOS to you

The BIOS runtime is hosted by the platform and makes outbound HTTPS calls to your API base URL. You install nothing: you expose your API and one identity endpoint (the auth-bridge). The egress IP list is published so you can restrict your firewall.

No lock-in

Open standards

Generated tools ship as a standard MCP server and your backend surface is described in OpenAPI 3.1. No black boxes.

Multi-tenant

Isolated by design

Each partner is a database-level isolated tenant. Your data, clients and credentials never cross with another partner's.

Glossary

Term	What it is
Product	Your software connected to BIOS (its code, API and manual).
Assistant	A configured agent: role, tone, instructions and automations.
Environment	An environment of your software (production, staging…) with its base URL and credentials.
Deployment	The assistant × product × environment combination that gets published.
Tool / Skill	One API operation turned into a tool · a complete frontend flow.
Auth-bridge	The signed webhook you implement to resolve each end user's identity.
Verification Key	The shared secret used to sign every auth-bridge call.
Contract test	The automatic validation a tool must pass before publishing.

S2 · Connect

Onboarding & ingestion

Three ways to connect your software, and what happens from connection until the agent is ready.

OpenAPI

Your API spec

Upload the file or point to your spec URL (up to 10 MB). The most direct path if you already document your API.

Git

Repository via OAuth

Connect GitHub, GitLab or Bitbucket with OAuth. BIOS reads the code, extracts your API surface and stays hooked to your releases.

ZIP

Packaged code

No accessible repo? Upload the code as a ZIP up to 100 MB. The frontend can come the same way, and manuals as PDF, DOCX, MD or HTML.

What happens on connect: the 3-agent flow

Parallel analysis

One agent reads your frontend and writes the user manual; another reads your backend and generates the OpenAPI spec of your real API.

Cross-reference

Both views are crossed: every business function in the UI gets linked to the endpoints that execute it. Gaps are detected and retried.

Build & verify

A third agent generates the tools and skills. Every unit passes mirrored verification (an executor plus an independent verifier) and the final contract-test gate before publishing.

Result: a versioned catalog of tools and skills, a user manual and a technical manual — generated from your real code, not from guesses.

S3 · Identity

Auth-bridge

The key piece: your users never do OAuth. Your system exposes one signed webhook and BIOS acts with each user's identity and permissions, message by message.

On every end-user message, BIOS calls a single endpoint you implement. Your system resolves who they are (by phone, email or channel username) and returns a per-turn token with their permissions. No token caching, no OAuth involved.

The request you receive

POST /bios/auth-bridge HTTP/1.1
Content-Type: application/json
User-Agent: NordixBIOS-Runtime/1
X-BIOS-Timestamp: 1785851520
X-BIOS-Nonce: 9b2f7c1e-4c9a-4b7e-9d3f-2f8a1c6e5d40
X-BIOS-Key-Id: vk_2
X-BIOS-Delivery: dl_01J9…
X-BIOS-Signature: v1=3f1a9c…e2

{
  "version": "1",
  "deploymentId": "dep_9f2c…",
  "channel": "whatsapp",
  "channelUserId": "+34 612 345 678",
  "identifierType": "phone",
  "requestedAt": "2026-07-28T10:12:00Z",
  "context": { "messageId": "wamid.HBg…", "locale": "es" }
}

Verifying the signature (HMAC v1)

The string to sign is timestamp \n nonce \n "POST" \n path \n sha256(body), signed with your Verification Key. Reject requests outside the ±300 s window and repeated nonces (cache ≥ 5 min). Always compare in constant time.

import crypto from "node:crypto";

export function verifyBiosSignature(headers, rawBody, verificationKey, path) {
  const ts = headers["x-bios-timestamp"];
  const nonce = headers["x-bios-nonce"];
  const sig = (headers["x-bios-signature"] || "").replace(/^v1=/, "");
  if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false;  // ±300 s
  const bodyHash = crypto.createHash("sha256").update(rawBody).digest("hex");
  const signingString = [ts, nonce, "POST", path, bodyHash].join("\n");
  const expected = crypto
    .createHmac("sha256", verificationKey)
    .update(signingString)
    .digest("hex");
  return crypto.timingSafeEqual(Buffer.from(sig, "hex"), Buffer.from(expected, "hex"));
}

import hashlib, hmac, time

def verify_bios_signature(headers, raw_body: bytes, verification_key: str, path: str) -> bool:
    ts = headers["X-BIOS-Timestamp"]
    nonce = headers["X-BIOS-Nonce"]
    sig = headers["X-BIOS-Signature"].removeprefix("v1=")
    if abs(time.time() - float(ts)) > 300:          # ±300 s
        return False
    body_hash = hashlib.sha256(raw_body).hexdigest()
    signing_string = "\n".join([ts, nonce, "POST", path, body_hash])
    expected = hmac.new(verification_key.encode(), signing_string.encode(),
                        hashlib.sha256).hexdigest()
    return hmac.compare_digest(sig, expected)

function verify_bios_signature(array $headers, string $rawBody,
                                string $key, string $path): bool {
    $ts = $headers['X-BIOS-Timestamp'];
    $nonce = $headers['X-BIOS-Nonce'];
    $sig = str_replace('v1=', '', $headers['X-BIOS-Signature']);
    if (abs(time() - (int)$ts) > 300) return false;      // ±300 s
    $signing = implode("\n", [$ts, $nonce, 'POST', $path, hash('sha256', $rawBody)]);
    $expected = hash_hmac('sha256', $signing, $key);
    return hash_equals($expected, $sig);
}

# Petición firmada de prueba (ilustrativa, para test local)
BODY='{"version":"1","deploymentId":"dep_9f2c","channel":"web","channelUserId":"u1","identifierType":"username","requestedAt":"2026-07-28T10:12:00Z"}'
TS=$(date +%s); NONCE=$(uuidgen)
HASH=$(printf '%s' "$BODY" | shasum -a 256 | cut -d' ' -f1)
SIGNING=$(printf '%s\n%s\nPOST\n/bios/auth-bridge\n%s' "$TS" "$NONCE" "$HASH")
SIG=$(printf '%s' "$SIGNING" | openssl dgst -sha256 -hmac "{{VERIFICATION_KEY}}" -hex | sed 's/^.* //')

curl -X POST https://tu-api.example.com/bios/auth-bridge \
  -H "Content-Type: application/json" \
  -H "X-BIOS-Timestamp: $TS" -H "X-BIOS-Nonce: $NONCE" \
  -H "X-BIOS-Signature: v1=$SIG" \
  -d "$BODY"

Your response

Return ok with one or more accounts, or unknown_user / blocked. The ids you declare are injected automatically into each tool's identity parameters — the model can never spoof them.

{
  "status": "ok",
  "accounts": [{
    "key": "default",
    "token": "usr_4821_t",
    "tokenType": "bearer",
    "user": { "id": "u_4821", "displayName": "Carmen", "locale": "es-ES" },
    "scopes": ["bookings:rw"],
    "ids": [{ "name": "customer_id", "value": "4821" }]
  }]
}

// status: "ok" | "unknown_user" | "blocked"

Code generator + Pull Request

You don't have to write it: BIOS detects your framework and generates the full endpoint (verifier + handler + .env.example, secret always via environment variable). And if you want, it opens the PR in your repository on branch nordixbios/auth-bridge-v{N} — it never writes to your base branch.

# 1 · Genera el bundle (verifier + handler + .env.example) — 202, ejecución en curso
curl -X POST {{API_BASE}}/v1/assistants/{aid}/deployments/{did}/auth-bridge/generate \
  -H "X-API-Key: {{API_KEY}}" -H "Idempotency-Key: 7f3a1c9e"

# 2 · Revisa el código generado
curl {{API_BASE}}/v1/assistants/{aid}/deployments/{did}/auth-bridge/generated-code \
  -H "X-API-Key: {{API_KEY}}"

# 3 · Abre el Pull Request en tu repositorio
curl -X POST {{API_BASE}}/v1/assistants/{aid}/deployments/{did}/auth-bridge/commit \
  -H "X-API-Key: {{API_KEY}}" -H "Content-Type: application/json" \
  -d '{"confirm": true}'
# → { "prUrl": "https://github.com/tu-org/tu-repo/pull/128",
#     "branch": "nordixbios/auth-bridge-v3" }

Language	Detected frameworks
Node.js	NestJS · Fastify · Koa · Express
PHP	Laravel · Symfony · Slim
Python	Django · FastAPI · Flask
Go	Gin · Echo · Chi · Fiber
Ruby / C# / Java	Rails · ASP.NET · Spring

Zero-downtime key rotation: during the rotation window the old and new keys coexist; the X-BIOS-Key-Id header tells you which one signed each call, and the history is audited. PR errors: 409 if the Git connection lacks write scopes · 502 if your Git provider fails.

S4 · Catalog

Tools, skills & lifecycle

How tools are generated, verified, versioned and maintained — including the automatic reaction to every release of your software.

Generation

Every operation, one tool

Creating a booking, issuing an invoice, moving stock: every operation of your API becomes a tool with its schema, version and success rate measured in production.

Contract tests

What doesn't pass, doesn't ship

Before publishing, every tool passes a contract test: a re-handshake against your auth-bridge and strict validation against the OpenAPI. Red means it doesn't go out.

Rollback

One click back

Every change is versioned with its diff. If something breaks after an update, automatic rollback to the last verified version — your refinements are never lost.

Edits

Tune without fear

Edit a tool by hand or with AI: coherence is always validated, and items you mark as protected are untouched by regenerations.

Releases: the autonomous loop

Detection

A push to your repository fires the webhook (signed per provider); a backup poll runs every 10 minutes.

Incremental diff

BIOS analyzes what changed and regenerates only what's affected — screens, functions and tools linked to the change. Whatever disappears from your code is retired from the catalog.

Verify & publish

Contract tests run again. Green: published. Red: automatic rollback and a notification.

Events you'll receive (webhooks and panel): sync_completed · sync_failed · sync_rollback · user_linked · operation_failed · cost_limit · credit_exhausted. Sync policy can be automatic or manual per deployment.

S5 · Channels

Channels

Seven channels included, connected per environment. What you provide for each one.

Each channel connects to one specific environment (production, staging…), unique per assistant + environment + type. Credentials are encrypted at rest and only masked versions appear in listings.

Channel	How it connects	What you provide
WhatsApp	Official Meta API (Cloud API)	`phoneNumberId` + `accessToken`, or guided OAuth (Embedded Signup)
Telegram	Bot API	Bot token (from @BotFather)
Microsoft Teams	Bot Framework (OAuth)	`appId` + `tenantId` + `clientSecret`
Slack	Events API (OAuth)	OAuth install → `botToken`
Messenger · Instagram	Meta page OAuth	`pageAccessToken` + `appSecret`
Web widget	Embeddable script	Allow-listed domains; snippet generated from the panel
Email	3 modes	BIOS-managed mailbox · your IMAP/SMTP · OAuth (Gmail / Microsoft)

The web widget

<!-- Un snippet por asistente; solo funciona en los dominios permitidos -->
<script src="{{WIDGET_BASE}}/widget.js" async
  data-config='{
    "widgetId": "{{WIDGET_ID}}",
    "theme": "auto",
    "position": "bottom-right"
  }'></script>

Agents read and generate attachments, show typing indicators, keep per-user memory and escalate to a human when needed — on every channel. The panel playground lets you test any simulated channel before publishing.

S6 · API

REST API & outbound webhooks

Automate BIOS from your own software: API keys with scopes, idempotency, and signed webhooks to your system.

Authentication & usage

Create API keys from the panel with scope read (reads) or write (writes). Send them in the X-API-Key header. The secret is shown only on creation or reveal — and every reveal is audited.

curl "{{API_BASE}}/v1/assistants?page=1&perPage=20" \
  -H "X-API-Key: {{API_KEY}}"

# Escrituras: añade Idempotency-Key para reintentos seguros (ventana 24 h)
curl -X POST "{{API_BASE}}/v1/…" \
  -H "X-API-Key: {{API_KEY}}" \
  -H "Idempotency-Key: 2b9d4f7a" \
  -d '{ … }'

const res = await fetch(`${API_BASE}/v1/assistants?page=1&perPage=20`, {
  headers: { "X-API-Key": process.env.BIOS_API_KEY },
});
if (res.status === 429) {
  const retryAfter = Number(res.headers.get("Retry-After") || 1);
  // espera y reintenta
}
const { data } = await res.json();

import os, requests

res = requests.get(
    f"{API_BASE}/v1/assistants",
    params={"page": 1, "perPage": 20},
    headers={"X-API-Key": os.environ["BIOS_API_KEY"]},
)
res.raise_for_status()
data = res.json()["data"]

Rate limit

600 req/min per key

With RateLimit-Limit / Remaining / Reset headers and Retry-After on 429. Raise the limit with your agreement.

Idempotency

Safe retries

Add Idempotency-Key to any write: same body within 24 h → same response; different body → 409.

Pagination

Predictable

page ≥ 1 and perPage between 1 and 100 (default 20) on every listing.

Webhooks to your system

Subscribe to events (sync_completed, sync_failed, user_linked, operation_failed…) and receive them signed with the same HMAC v1 scheme as the auth-bridge: verify with the same code. Delivery is at-least-once — deduplicate by X-BIOS-Delivery. From the panel you can test the endpoint, rotate the secret and redeliver any delivery.

S7 · Limits

Limits & quotas

Every technical limit in one table, so you can size your integration with no surprises.

Concept	Limit
Agent turns per conversation	8 turns · 60 s per turn
Source code (ZIP)	up to 100 MB
OpenAPI (URL or file)	up to 10 MB
Manual documents	PDF · DOCX · MD · HTML
API key rate limit	600 req/min (raisable by agreement)
Idempotency window	24 h per `Idempotency-Key`
Pagination	1–100 per page (default 20)
Auth-bridge anti-replay	±300 s · single-use nonce (cache ≥ 5 min)
Release detection	push webhook + 10-min poll
Outbound webhooks	at-least-once · dedup by `X-BIOS-Delivery`

Usage limits (messages, active users, tokens) depend on your agreement and are managed from the Billing panel, with spend ceilings and alerts you define.

S8 · Security

Security & compliance

Multi-tenant isolation, encryption, data residency in Spain, and an identity the model cannot spoof.

Isolation

RLS enforced at the database

Row-Level Security active and forced on tenant tables: the partner identifier always comes from the token, never from the request. Another tenant's resource simply doesn't exist (404).

Encryption

AES-256-GCM at application level

Credentials and secrets encrypted with AES-256-GCM at the application level before reaching the database; listings only carry masked versions and every reveal is audited.

Data residency

Spain (EU)

Data and database in region eu-south-2 (Zaragoza); transactional email is sent from eu-north-1 (Stockholm). Everything within the EU.

Non-spoofable identity

Parameters only from the auth-bridge

Each tool's identity parameters are injected from your auth-bridge's verified response: the model cannot invent a customer_id.

Anti-SSRF

Triple egress barrier

Public-URL validation (cloud metadata blocked), destination allowlist and a cross-host redirect guard in the tool executor.

Access

RBAC + MFA

Roles owner / admin / member / billing / viewer, two-factor auth, revocable sessions and an opaque refresh token in an httpOnly cookie.

BIOS's egress IP list is published on the platform's public status page so you can firewall your auth-bridge and API.

S9 · Reference

Reference

The error contract, the API domains and how they evolve.

Error envelope

Every error shares the same shape — always keep the requestId for support:

{
  "error": {
    "code": "RATE_LIMITED",
    "message": "Too many requests",
    "details": { "limitPerMin": 600 },
    "requestId": "req_01J9…"
  }
}

Code	When
`400`	Invalid body or missing required fields
`401`	Invalid / expired signature or credential
`404`	Resource doesn't exist — including another tenant's
`409`	Conflict: Idempotency-Key reused with a different body · PR without write scopes
`422`	Schema validation failed
`429`	`RATE_LIMITED` — honor `Retry-After`

API domains

Over 200 endpoints under /v1, organized by domain: assistants (products, sources, deployments, auth-bridge, tools & skills, executions), channels, end users, schedules, billing, keys & webhooks and notifications. The full OpenAPI spec, with per-language examples, is delivered with your onboarding.

/v1 is stable: changes are additive. Breaking changes will be announced in advance and coexist with the previous version.

Technical questions? Let's solve them on a call.

Book a meeting

Teknisk dokumentasjon. Alt teamet ditt trenger.

Hvordan BIOS kobles til programvaren din, hvordan du verifiserer brukernes identitet, og grensene og garantiene du får. Skrevet for det tekniske teamet ditt.

S1 · Start her

Introduksjon

Hva BIOS er for en programvareeier, hvordan det kobles til, og ordforrådet som brukes i denne dokumentasjonen.

BIOS er infrastrukturen som bygger og drifter AI-agenter oppå programvaren din. Den kobles til produktet ditt via API-et (aldri skjermskraping eller RPA), genererer verktøyene som betjener det, og agentene betjener teamet ditt, bedriftene som bruker programvaren din og sluttkundene deres — alltid med den reelle brukerens identitet og tillatelser.

Arkitektur

All trafikk går fra BIOS til deg

BIOS-runtimen driftes av plattformen og gjør utgående HTTPS-kall til API-ets basis-URL. Du installerer ingenting: du eksponerer API-et ditt og ett identitetsendepunkt (auth-bridge). Utgående IP-liste er publisert så du kan begrense brannmuren din.

Ingen innlåsing

Åpne standarder

Genererte verktøy leveres som en standard MCP-server og backend-flaten beskrives i OpenAPI 3.1. Ingen svarte bokser.

Multi-tenant

Isolert by design

Hver partner er en isolert tenant på databasenivå. Dine data, kunder og hemmeligheter krysses aldri med en annen partners.

Ordliste

Begrep	Hva det er
Product	Programvaren din koblet til BIOS (kode, API og manual).
Assistant	En konfigurert agent: rolle, tone, instruksjoner og automatiseringer.
Environment	Et miljø av programvaren din (produksjon, staging…) med basis-URL og hemmeligheter.
Deployment	Kombinasjonen assistent × produkt × miljø som publiseres.
Tool / Skill	Én API-operasjon gjort om til verktøy · en komplett frontend-flyt.
Auth-bridge	Den signerte webhooken du implementerer for å løse hver sluttbrukers identitet.
Verification Key	Den delte hemmeligheten som signerer hvert auth-bridge-kall.
Contract test	Den automatiske valideringen et verktøy må bestå før publisering.

S2 · Koble til

Onboarding og innlesing

Tre måter å koble til programvaren din på, og hva som skjer fra tilkobling til agenten er klar.

OpenAPI

API-spesifikasjonen din

Last opp filen eller pek på spesifikasjonens URL (opptil 10 MB). Den mest direkte veien om du allerede dokumenterer API-et.

Git

Repositorium via OAuth

Koble til GitHub, GitLab eller Bitbucket med OAuth. BIOS leser koden, henter ut API-flaten og følger releasene dine.

ZIP

Pakket kode

Ikke noe tilgjengelig repo? Last opp koden som ZIP på opptil 100 MB. Frontenden kan komme samme vei, og manualer som PDF, DOCX, MD eller HTML.

Hva skjer ved tilkobling: 3-agent-flyten

Parallell analyse

Én agent leser frontenden din og skriver brukermanualen; en annen leser backenden og genererer OpenAPI-spesifikasjonen til det reelle API-et ditt.

Kryssreferanse

De to visningene krysses: hver forretningsfunksjon i grensesnittet knyttes til endepunktene som utfører den. Hull oppdages og prøves på nytt.

Bygg og verifiser

En tredje agent genererer verktøyene og skillsene. Hver enhet består speilet verifisering (en utfører pluss en uavhengig verifikator) og den endelige contract-test-porten før publisering.

Resultat: en versjonert katalog av tools og skills, en brukermanual og en teknisk manual — generert fra din reelle kode, ikke fra antakelser.

S3 · Identitet

Auth-bridge

Nøkkelbrikken: brukerne dine gjør aldri OAuth. Systemet ditt eksponerer én signert webhook og BIOS handler med hver brukers identitet og tillatelser, melding for melding.

Ved hver sluttbrukermelding kaller BIOS ett enkelt endepunkt du implementerer. Systemet ditt løser hvem de er (via telefon, e-post eller kanalbrukernavn) og returnerer et token per tur med deres tillatelser. Ingen token-caching, ingen OAuth.

Forespørselen du mottar

POST /bios/auth-bridge HTTP/1.1
Content-Type: application/json
User-Agent: NordixBIOS-Runtime/1
X-BIOS-Timestamp: 1785851520
X-BIOS-Nonce: 9b2f7c1e-4c9a-4b7e-9d3f-2f8a1c6e5d40
X-BIOS-Key-Id: vk_2
X-BIOS-Delivery: dl_01J9…
X-BIOS-Signature: v1=3f1a9c…e2

{
  "version": "1",
  "deploymentId": "dep_9f2c…",
  "channel": "whatsapp",
  "channelUserId": "+34 612 345 678",
  "identifierType": "phone",
  "requestedAt": "2026-07-28T10:12:00Z",
  "context": { "messageId": "wamid.HBg…", "locale": "es" }
}

Verifisere signaturen (HMAC v1)

Strengen som signeres er timestamp \n nonce \n "POST" \n path \n sha256(body), signert med din Verification Key. Avvis forespørsler utenfor ±300 s-vinduet og gjentatte nonces (cache ≥ 5 min). Sammenlign alltid i konstant tid.

import crypto from "node:crypto";

export function verifyBiosSignature(headers, rawBody, verificationKey, path) {
  const ts = headers["x-bios-timestamp"];
  const nonce = headers["x-bios-nonce"];
  const sig = (headers["x-bios-signature"] || "").replace(/^v1=/, "");
  if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false;  // ±300 s
  const bodyHash = crypto.createHash("sha256").update(rawBody).digest("hex");
  const signingString = [ts, nonce, "POST", path, bodyHash].join("\n");
  const expected = crypto
    .createHmac("sha256", verificationKey)
    .update(signingString)
    .digest("hex");
  return crypto.timingSafeEqual(Buffer.from(sig, "hex"), Buffer.from(expected, "hex"));
}

import hashlib, hmac, time

def verify_bios_signature(headers, raw_body: bytes, verification_key: str, path: str) -> bool:
    ts = headers["X-BIOS-Timestamp"]
    nonce = headers["X-BIOS-Nonce"]
    sig = headers["X-BIOS-Signature"].removeprefix("v1=")
    if abs(time.time() - float(ts)) > 300:          # ±300 s
        return False
    body_hash = hashlib.sha256(raw_body).hexdigest()
    signing_string = "\n".join([ts, nonce, "POST", path, body_hash])
    expected = hmac.new(verification_key.encode(), signing_string.encode(),
                        hashlib.sha256).hexdigest()
    return hmac.compare_digest(sig, expected)

function verify_bios_signature(array $headers, string $rawBody,
                                string $key, string $path): bool {
    $ts = $headers['X-BIOS-Timestamp'];
    $nonce = $headers['X-BIOS-Nonce'];
    $sig = str_replace('v1=', '', $headers['X-BIOS-Signature']);
    if (abs(time() - (int)$ts) > 300) return false;      // ±300 s
    $signing = implode("\n", [$ts, $nonce, 'POST', $path, hash('sha256', $rawBody)]);
    $expected = hash_hmac('sha256', $signing, $key);
    return hash_equals($expected, $sig);
}

# Petición firmada de prueba (ilustrativa, para test local)
BODY='{"version":"1","deploymentId":"dep_9f2c","channel":"web","channelUserId":"u1","identifierType":"username","requestedAt":"2026-07-28T10:12:00Z"}'
TS=$(date +%s); NONCE=$(uuidgen)
HASH=$(printf '%s' "$BODY" | shasum -a 256 | cut -d' ' -f1)
SIGNING=$(printf '%s\n%s\nPOST\n/bios/auth-bridge\n%s' "$TS" "$NONCE" "$HASH")
SIG=$(printf '%s' "$SIGNING" | openssl dgst -sha256 -hmac "{{VERIFICATION_KEY}}" -hex | sed 's/^.* //')

curl -X POST https://tu-api.example.com/bios/auth-bridge \
  -H "Content-Type: application/json" \
  -H "X-BIOS-Timestamp: $TS" -H "X-BIOS-Nonce: $NONCE" \
  -H "X-BIOS-Signature: v1=$SIG" \
  -d "$BODY"

Svaret ditt

Returner ok med én eller flere kontoer, eller unknown_user / blocked. ids-ene du oppgir injiseres automatisk i hvert verktøys identitetsparametre — modellen kan aldri forfalske dem.

{
  "status": "ok",
  "accounts": [{
    "key": "default",
    "token": "usr_4821_t",
    "tokenType": "bearer",
    "user": { "id": "u_4821", "displayName": "Carmen", "locale": "es-ES" },
    "scopes": ["bookings:rw"],
    "ids": [{ "name": "customer_id", "value": "4821" }]
  }]
}

// status: "ok" | "unknown_user" | "blocked"

Kodegenerator + Pull Request

Du trenger ikke skrive det selv: BIOS oppdager rammeverket ditt og genererer hele endepunktet (verifikator + handler + .env.example, hemmeligheten alltid via miljøvariabel). Og om du vil, åpner den PR-en i repositoriet ditt på branchen nordixbios/auth-bridge-v{N} — den skriver aldri til basisbranchen din.

# 1 · Genera el bundle (verifier + handler + .env.example) — 202, ejecución en curso
curl -X POST {{API_BASE}}/v1/assistants/{aid}/deployments/{did}/auth-bridge/generate \
  -H "X-API-Key: {{API_KEY}}" -H "Idempotency-Key: 7f3a1c9e"

# 2 · Revisa el código generado
curl {{API_BASE}}/v1/assistants/{aid}/deployments/{did}/auth-bridge/generated-code \
  -H "X-API-Key: {{API_KEY}}"

# 3 · Abre el Pull Request en tu repositorio
curl -X POST {{API_BASE}}/v1/assistants/{aid}/deployments/{did}/auth-bridge/commit \
  -H "X-API-Key: {{API_KEY}}" -H "Content-Type: application/json" \
  -d '{"confirm": true}'
# → { "prUrl": "https://github.com/tu-org/tu-repo/pull/128",
#     "branch": "nordixbios/auth-bridge-v3" }

Språk	Oppdagede rammeverk
Node.js	NestJS · Fastify · Koa · Express
PHP	Laravel · Symfony · Slim
Python	Django · FastAPI · Flask
Go	Gin · Echo · Chi · Fiber
Ruby / C# / Java	Rails · ASP.NET · Spring

Nøkkelrotasjon uten nedetid: i rotasjonsvinduet gjelder gammel og ny nøkkel samtidig; X-BIOS-Key-Id-headeren forteller hvilken som signerte hvert kall, og historikken revideres. PR-feil: 409 hvis Git-tilkoblingen mangler skrivetilgang · 502 hvis Git-leverandøren feiler.

S4 · Katalog

Tools, skills og livssyklus

Hvordan verktøy genereres, verifiseres, versjoneres og vedlikeholdes — inkludert den automatiske reaksjonen på hver release.

Generering

Hver operasjon, ett verktøy

Opprette en bestilling, utstede en faktura, flytte lager: hver operasjon i API-et ditt blir et verktøy med skjema, versjon og suksessrate målt i produksjon.

Contract tests

Det som ikke består, publiseres ikke

Før publisering består hvert verktøy en contract test: re-handshake mot auth-bridgen din og streng validering mot OpenAPI-en. Rødt betyr at det ikke går ut.

Tilbakerulling

Ett klikk tilbake

Hver endring versjoneres med sin diff. Om noe ryker etter en oppdatering: automatisk tilbakerulling til siste verifiserte versjon — forbedringene dine går aldri tapt.

Redigering

Juster uten frykt

Rediger et verktøy manuelt eller med AI: koherens valideres alltid, og elementer du merker som beskyttet røres ikke av regenereringer.

Releaser: den autonome løkken

Oppdagelse

Et push til repositoriet ditt utløser webhooken (signert per leverandør); en reservesondering kjører hvert 10. minutt.

Inkrementell diff

BIOS analyserer hva som endret seg og regenererer bare det berørte — skjermer, funksjoner og verktøy knyttet til endringen. Det som forsvinner fra koden din, trekkes fra katalogen.

Verifiser og publiser

Contract-testene kjøres igjen. Grønt: publisert. Rødt: automatisk tilbakerulling og varsel.

Hendelser du mottar (webhooks og panel): sync_completed · sync_failed · sync_rollback · user_linked · operation_failed · cost_limit · credit_exhausted. Sync-policyen kan være automatisk eller manuell per deployment.

S5 · Kanaler

Kanaler

Sju kanaler inkludert, koblet per miljø. Hva du bidrar med for hver.

Hver kanal kobles til ett bestemt miljø (produksjon, staging…), unik per assistent + miljø + type. Hemmeligheter krypteres i ro og vises kun maskert i lister.

Kanal	Hvordan den kobles	Hva du bidrar med
WhatsApp	Offisiell Meta-API (Cloud API)	`phoneNumberId` + `accessToken`, eller veiledet OAuth (Embedded Signup)
Telegram	Bot API	Bot-token (fra @BotFather)
Microsoft Teams	Bot Framework (OAuth)	`appId` + `tenantId` + `clientSecret`
Slack	Events API (OAuth)	OAuth-installasjon → `botToken`
Messenger · Instagram	Meta side-OAuth	`pageAccessToken` + `appSecret`
Web-widget	Innbyggbart script	Tillatte domener; snippet genereres fra panelet
E-post	3 moduser	BIOS-administrert postkasse · din IMAP/SMTP · OAuth (Gmail / Microsoft)

Web-widgeten

<!-- Un snippet por asistente; solo funciona en los dominios permitidos -->
<script src="{{WIDGET_BASE}}/widget.js" async
  data-config='{
    "widgetId": "{{WIDGET_ID}}",
    "theme": "auto",
    "position": "bottom-right"
  }'></script>

Agentene leser og genererer vedlegg, viser skriveindikator, holder minne per bruker og eskalerer til et menneske ved behov — i alle kanaler. Playgrounden i panelet lar deg teste enhver simulert kanal før publisering.

S6 · API

REST-API og utgående webhooks

Automatiser BIOS fra din egen programvare: API-nøkler med scopes, idempotens og signerte webhooks til systemet ditt.

Autentisering og bruk

Opprett API-nøkler fra panelet med scope read (lesing) eller write (skriving). Send dem i X-API-Key-headeren. Hemmeligheten vises kun ved opprettelse eller avsløring — og hver avsløring revideres.

curl "{{API_BASE}}/v1/assistants?page=1&perPage=20" \
  -H "X-API-Key: {{API_KEY}}"

# Escrituras: añade Idempotency-Key para reintentos seguros (ventana 24 h)
curl -X POST "{{API_BASE}}/v1/…" \
  -H "X-API-Key: {{API_KEY}}" \
  -H "Idempotency-Key: 2b9d4f7a" \
  -d '{ … }'

const res = await fetch(`${API_BASE}/v1/assistants?page=1&perPage=20`, {
  headers: { "X-API-Key": process.env.BIOS_API_KEY },
});
if (res.status === 429) {
  const retryAfter = Number(res.headers.get("Retry-After") || 1);
  // espera y reintenta
}
const { data } = await res.json();

import os, requests

res = requests.get(
    f"{API_BASE}/v1/assistants",
    params={"page": 1, "perPage": 20},
    headers={"X-API-Key": os.environ["BIOS_API_KEY"]},
)
res.raise_for_status()
data = res.json()["data"]

Rate limit

600 req/min per nøkkel

Med RateLimit-Limit / Remaining / Reset-headere og Retry-After ved 429. Grensen kan økes i avtalen din.

Idempotens

Trygge omforsøk

Legg til Idempotency-Key på enhver skriving: samme body innen 24 t → samme svar; annen body → 409.

Paginering

Forutsigbar

page ≥ 1 og perPage mellom 1 og 100 (standard 20) i alle lister.

Webhooks til systemet ditt

Abonner på hendelser (sync_completed, sync_failed, user_linked, operation_failed…) og motta dem signert med samme HMAC v1-skjema som auth-bridgen: verifiser med samme kode. Levering er at-least-once — dedupliser med X-BIOS-Delivery. Fra panelet kan du teste endepunktet, rotere hemmeligheten og sende enhver levering på nytt.

S7 · Grenser

Grenser og kvoter

Alle tekniske grenser i én tabell, så du kan dimensjonere integrasjonen uten overraskelser.

Konsept	Grense
Agent-turer per samtale	8 turer · 60 s per tur
Kildekode (ZIP)	opptil 100 MB
OpenAPI (URL eller fil)	opptil 10 MB
Manualdokumenter	PDF · DOCX · MD · HTML
Rate limit for API-nøkler	600 req/min (kan økes i avtalen)
Idempotensvindu	24 t per `Idempotency-Key`
Paginering	1–100 per side (standard 20)
Auth-bridge anti-replay	±300 s · engangs-nonce (cache ≥ 5 min)
Release-oppdagelse	push-webhook + sondering hvert 10. min
Utgående webhooks	at-least-once · dedup med `X-BIOS-Delivery`

Forbruksgrenser (meldinger, aktive brukere, tokens) avhenger av avtalen din og styres fra Billing-panelet, med kostnadstak og varsler du definerer.

S8 · Sikkerhet

Sikkerhet og etterlevelse

Multi-tenant-isolasjon, kryptering, dataresidens i Spania og en identitet modellen ikke kan forfalske.

Isolasjon

RLS håndhevet i databasen

Row-Level Security aktiv og tvunget på tenant-tabellene: partner-identifikatoren kommer alltid fra tokenet, aldri fra forespørselen. En annen tenants ressurs finnes rett og slett ikke (404).

Kryptering

AES-256-GCM på applikasjonsnivå

Hemmeligheter krypteres med AES-256-GCM på applikasjonsnivå før de når databasen; lister bærer kun maskerte versjoner og hver avsløring revideres.

Dataresidens

Spania (EU)

Data og database i regionen eu-south-2 (Zaragoza); transaksjons-e-post sendes fra eu-north-1 (Stockholm). Alt innenfor EU.

Uforfalskbar identitet

Parametre kun fra auth-bridgen

Hvert verktøys identitetsparametre injiseres fra auth-bridgens verifiserte svar: modellen kan ikke finne på en customer_id.

Anti-SSRF

Trippel utgående barriere

Validering av offentlig URL (sky-metadata blokkert), destinasjons-allowlist og redirect-vakt mellom verter i verktøyutføreren.

Tilgang

RBAC + MFA

Roller owner / admin / member / billing / viewer, tofaktor, tilbakekallbare økter og opakt refresh-token i httpOnly-cookie.

BIOS' utgående IP-liste er publisert på plattformens offentlige statusside slik at du kan brannmurbeskytte auth-bridgen og API-et ditt.

S9 · Referanse

Referanse

Feilkontrakten, API-domenene og hvordan de utvikler seg.

Feilkonvolutt

Alle feil deler samme form — ta alltid vare på requestId for support:

{
  "error": {
    "code": "RATE_LIMITED",
    "message": "Too many requests",
    "details": { "limitPerMin": 600 },
    "requestId": "req_01J9…"
  }
}

Kode	Når
`400`	Ugyldig body eller manglende obligatoriske felt
`401`	Ugyldig / utløpt signatur eller legitimasjon
`404`	Ressursen finnes ikke — inkludert en annen tenants
`409`	Konflikt: Idempotency-Key gjenbrukt med annen body · PR uten skrivetilgang
`422`	Skjemavalidering feilet
`429`	`RATE_LIMITED` — respekter `Retry-After`

API-domener

Over 200 endepunkter under /v1, organisert etter domene: assistants (produkter, kilder, deployments, auth-bridge, tools & skills, kjøringer), channels, slutt-users, schedules, billing, keys & webhooks og notifications. Den komplette OpenAPI-spesifikasjonen, med eksempler per språk, leveres ved onboarding.

/v1 er stabil: endringer er additive. Brytende endringer varsles på forhånd og sameksisterer med forrige versjon.

Tekniske spørsmål? Vi løser dem i en samtale.

Avtal et møte