Desarrolla con Praxium.

Las claves de API se firman con HMAC al crearlas: la clave lleva su propia prueba de integridad con el formato praxium_v1_<tenant>_<profile>_<timestamp>_<signature>, donde la firma se deriva en el servidor con HMAC-SHA256 a partir de un secreto de firma propio de cada perfil que se guarda cifrado en la base de datos — el secreto nunca viaja por la red, solo viaja la firma que produce. El nombre corto de la organización queda unido criptográficamente a la firma, así que una clave emitida para la organización A no se puede reutilizar en la organización B sin romper la verificación. Al llegar, el servidor comprueba la integridad de la clave antes de devolver ningún dato, y las claves falsificadas o reutilizadas reciben un 403.

Las peticiones se autentican con el habitual Authorization: Bearer <key> sobre HTTPS — el mismo patrón que usan GitHub, OpenAI, Slack y Notion.

Además, cada clave pertenece a un único perfil de API, que define exactamente qué tipos de datos y campos puede leer. Cada integración toca solo los datos que necesita — el principio de mínimo privilegio, aplicado campo a campo y no endpoint a endpoint. La revocación y la rotación se hacen por perfil desde el portal de administración.

Envía Accept-Language: nl, Accept-Language: en o Accept-Language: ro cuando tu sitio muestre un solo idioma. La API usa el idioma pedido solo si la organización lo tiene activado; si no, usa su idioma predeterminado.

Cada endpoint mantiene una sola forma de respuesta documentada. Los campos documentados como traducidos — nombres de categorías de las FAQ, preguntas y respuestas, etiquetas y valores de los campos personalizados del equipo — vuelven como cadenas. Los campos documentados en OpenAPI como mapas de idiomas conservan esa forma.

En los campos traducidos, una traducción que falta cae al mejor texto publicado disponible en lugar de a una cadena vacía.

Cada entrega lleva una sola cabecera X-Praxium-Signature: t=<unix_ts>,sha256=<hmac_hex>, donde el HMAC-SHA256 se calcula en el servidor sobre ${timestamp}.${rawBody} con el secreto de ese webhook. El secreto compartido nunca viaja por la red — solo viaja el resultado del HMAC. La firma demuestra dos cosas a la vez: que el cuerpo no se alteró por el camino (integridad) y que la llamada viene de verdad de Praxium y no de alguien que adivinó la dirección de tu endpoint (autenticidad). Todas las entregas van por HTTPS — Praxium se niega a registrar direcciones de webhook que no sean HTTPS en los entornos publicados.

Quien recibe un webhook tiene que verificar cada entrega — Praxium firma y envía, pero la comprobación ocurre en tu manejador. Si usas @praxium/sdk no escribes nada de esto a mano: processWebhook() (independiente del framework) y createRevalidationHandler() (ISR de Next.js) hacen los cuatro pasos y además protegen frente a reenvíos. ¿Lo implementas en otro entorno? Los cuatro pasos son: (1) lee el momento y la firma de la cabecera, (2) rechaza las entregas más antiguas que tu ventana de reenvío — 5 minutos es lo habitual, (3) recalcula el HMAC sobre ${timestamp}.${rawBody} con tu secreto compartido, (4) compara con una comparación de tiempo constante (por ejemplo crypto.timingSafeEqual en Node).

Es el mismo esquema que usa Stripe para firmar sus webhooks. Los secretos de cada webhook se muestran una sola vez — en la respuesta que crea el webhook y en cada respuesta de rotación — y después no vuelven a aparecer. Esa exposición única significa que en la plataforma no queda una superficie de ataque duradera para el secreto: ni siquiera una sesión de administración comprometida podría volver a leerlo. ¿Necesitas uno nuevo? Rótalo desde el portal de administración — el secreto nuevo llega en la respuesta, el anterior deja de valer al momento y las demás suscripciones no se tocan.