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.0Permite 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.
Depende de
Lo necesitan otros módulos
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-03Estado de confirmación: 5 confirmadas, 4 sin información de 9 versiones.
Fuentes · Odoo 16.0
Confirmado el 2026-11-03 en la rama 16.0 de OCA/web-api.
terminal Instalación y uso
Documentación de OCA · Odoo 19.0Configuración
Fuente · Odoo 19.0Los 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 deendpoint.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,PUToDELETE. Las peticiones que usan cualquier otro método se rechazan con405 Method Not Allowed. - Tipo de contenido de la petición:
Content-Typeesperado del cuerpo de la petición entrante. Obligatorio paraPOST/PUT. Valores disponibles: text/plain,text/csvapplication/jsonapplication/xmlapplication/x-www-form-urlencodedCuando se establece, las peticiones con una cabeceraContent-Typediferente se rechazan con415 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 mediantesafe_evalpara cada petición. El fragmento debe asignar undicta la variableresult; puede contener unResponseya preparado (bajo la claveresponse) opayload,headersystatus_codepara 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,requestdatetime,dateutil,time,jsonResponse(http.Responsede Odoo)werkzeug(limitado aNotFound,BadRequest,Unauthorized)exceptions(limitado aUserError,ValidationError)hashlib,hmac(subconjunto de la biblioteca estándar)log(message, level="info")— escribe enir.loggingLanzarUserErroroValidationErrordesde el fragmento se convierte en400 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.
Las instrucciones de instalación, el paquete de distribución, las dependencias y los pasos de configuración no se muestran porque todavía no se han verificado en la documentación del módulo para ninguna versión.
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.