OdooWiki OCA HUB
Sin categoría Licencia: LGPL-3

Proporciona un framework de endpoints que permite a los usuarios definir su propio endpoint personalizado.

Gracias al mixin de endpoint, los registros de endpoint se registran automáticamente como rutas reales de Odoo.

Puedes programar fácilmente lo que quieras en el fragmento de código.

NOTA: por razones de seguridad, cualquier tipo de llamada RPC está bloqueada en los registros de endpoint.

Traducción automática al español (DeepSeek) de la descripción original de OCA, que está en inglés.

auto_awesome Qué hace este módulo

Generado por IA a partir del código · Odoo 19.0

Permite a los administradores crear endpoints web personalizados directamente en Odoo rellenando un formulario, sin escribir un módulo de controlador. Cada endpoint puede validar JSON o XML entrante y ejecutar un pequeño fragmento de código para construir la respuesta.

Este módulo añade un menú "Endpoints" (bajo el menú Custom) donde los administradores pueden definir sus propios endpoints de API web como registros en lugar de escribir código en un módulo.

En cada registro de endpoint se establece la ruta URL, el método HTTP, el tipo de contenido, el tipo de autenticación y, para endpoints públicos, el usuario con el que debe ejecutarse la petición. También se puede restringir un endpoint a una compañía.

Para peticiones POST y PUT con contenido JSON o XML, se puede pegar un esquema opcional (JSON Schema o XSD). Odoo comprueba el esquema al guardar, y los cuerpos de las peticiones entrantes se validan contra él; los cuerpos no válidos se rechazan con un error 400 que enumera los problemas.

Cuando el modo de ejecución es "Execute code", se escribe un fragmento de Python que recibe variables útiles (environment, request, user, helpers para JSON, hashing y HMAC) y devuelve el payload, las cabeceras y el código de estado. Una pestaña "Code Help" documenta las variables disponibles. Una acción "Sync registry" hace efectivos los cambios guardados en el registro de enrutamiento.

Los endpoints son multi-company aware, y todas las llamadas RPC sobre registros de endpoint están bloqueadas por seguridad.

Modelos y campos (2)
  • endpoint.mixin · modelo nuevoexec_mode, company_id (Company), code_snippet, exec_as_user_id, code_snippet_docs, request_content_schema, request_content_schema_applicable
  • endpoint.endpoint · modelo nuevo

Texto generado por IA (DeepSeek) al leer el código de la versión 19.0 en GitHub; puede contener errores, así que verifícalo en el código antes de decidir. Ver el código en GitHub

Disponibilidad por versión

Revisado: 2026-11-03
Confirmado (verificado en repositorio y rama) Estimado (sin verificar) Sin información

Estado de confirmación: 5 confirmadas, 4 sin información de 9 versiones.

terminal Instalación y uso

Documentación de OCA · Odoo 19.0

Los endpoints se gestionan en Técnico → Endpoints.

Cada registro representa una única ruta HTTP expuesta por Odoo y ejecutada según su configuración.

Identificación

  • Nombre: etiqueta legible por humanos usada en listas y registros.
  • Ruta: ruta URL servida por el endpoint (p. ej. /my/custom/path). Las rutas deben ser únicas en todos los modelos endpoint-consumer, no solo dentro de endpoint.endpoint.
  • Grupo de ruta: etiqueta de texto libre para clasificar rutas relacionadas entre sí. Útil para filtrar y para módulos posteriores que agrupan endpoints.

Autenticación

  • Tipo de autenticación:
  • User: la petición debe estar autenticada como un usuario de Odoo (predeterminado).
  • Public: la ruta es accesible sin autenticación.
  • Ejecutar como usuario: el usuario bajo el cual se ejecuta el fragmento de código.
  • Obligatorio cuando el Tipo de autenticación es Public (el usuario público no tiene privilegios reales, por lo que el endpoint debe suplantar a un usuario real para realizar cualquier trabajo significativo).
  • Opcional en caso contrario; si se establece, el fragmento se evalúa como ese usuario en lugar del llamante.

Petición

  • Método de petición: GET, POST, PUT o DELETE. Las peticiones que usan cualquier otro método se rechazan con 405 Method Not Allowed.
  • Tipo de contenido de la petición: Content-Type esperado del cuerpo de la petición entrante. Obligatorio para POST/PUT. Valores disponibles:
  • text/plain, text/csv
  • application/json
  • application/xml
  • application/x-www-form-urlencoded Cuando se establece, las peticiones con una cabecera Content-Type diferente se rechazan con 415 Unsupported Media Type.

Esquema de contenido de la petición (opcional)

Para endpoints POST/PUT cuyo tipo de contenido es application/json o application/xml, se muestra una pestaña opcional Request Schema. Cuando se proporciona un esquema, el cuerpo de la petición se valida contra él antes de que se ejecute el fragmento de código; en caso de fallo, la petición se rechaza con un error de validación estructurado (RequestValidationError).

El formato de esquema aceptado depende del tipo de contenido:

  • JSON (application/json): un JSON Schema (Draft 2020-12). El campo acepta tanto sintaxis JSON como YAML — YAML es conveniente cuando se redactan esquemas en línea.
  • XML (application/xml): un XML Schema (XSD).

Ejemplo de JSON Schema (en forma YAML):

type: object
required: [name, qty]
properties:
  name: { type: string }
  qty:  { type: integer, minimum: 1 }

Ejemplo de XSD:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="greeting" type="xs:string"/>
</xs:schema>

> Consejo: al distribuir endpoints desde un módulo, el esquema puede residir en > un archivo separado y cargarse en el campo en el momento de la instalación usando el > atributo file en el registro de datos: > > ``xml > <field name="request_content_schema" type="char" file="endpoint/demo/content_schema.xsd" /> >``

Ejecución

  • Modo de ejecución: cómo se maneja la petición. El módulo base incluye Execute code; los módulos posteriores pueden registrar modos adicionales.
  • Fragmento de código (cuando el modo de ejecución es code): código Python evaluado mediante safe_eval para cada petición. El fragmento debe asignar un dict a la variable result; puede contener un Response ya preparado (bajo la clave response) o payload, headers y status_code para que los ensamble el framework. Variables expuestas al fragmento (consulta la pestaña Code Help del formulario para ver la lista actualizada en vivo):
  • env, user, endpoint, request
  • datetime, dateutil, time, json
  • Response (http.Response de Odoo)
  • werkzeug (limitado a NotFound, BadRequest, Unauthorized)
  • exceptions (limitado a UserError, ValidationError)
  • hashlib, hmac (subconjunto de la biblioteca estándar)
  • log(message, level="info") — escribe en ir.logging Lanzar UserError o ValidationError desde el fragmento se convierte en 400 Bad Request.

Fragmento mínimo:

result = {"response": Response("Hello, World!")}

Sincronización del registro

Los endpoints se registran en un registro de enrutamiento que vive fuera del ORM. Después de crear, modificar o archivar un registro, aparece la advertencia "Registry out of sync" en el formulario, y el registro se muestra en el filtro To sync de la vista de lista. Ejecuta la acción Sync registry para confirmar los cambios en la tabla de enrutamiento activa — hasta entonces, la nueva configuración no se sirve.

Traducción automática al español (DeepSeek) de la documentación original de OCA; los comandos y el código no se traducen. Sin información verificada en OCA: Instalación, Uso.

info

Datos importados de GitHub: esta ficha refleja la última revisión del catálogo, no una consulta en directo. Verifica siempre en la documentación del módulo y en staging antes de instalar en producción.