Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.enneo.ai/llms.txt

Use this file to discover all available pages before exploring further.

Enneo can be extended at many points with custom code. This allows peripheral systems to be connected, business logic to be mapped, and automations to be implemented without changing the platform itself.

​
Where custom code in Enneo is used

Custom code in Enneo is always stored as a so-called Executor and referenced in various places. Typical areas of application include:
  • Customer Recognition — Search by contract number, customer number, attributes or free text relies on own functions that load data from the ERP or other source systems.
  • Rule-Based AI Agents — The business logic of an agent (e.g., capturing meter reading, writing address change, canceling contract) calls own code to perform the actual action in the peripheral system.
  • AI Tools for Smart AI Agents — Smart (LLM-based) agents decide on their own during a conversation which tool they call. Each user-defined tool (managed under AI Customization → AI Tools) is an Executor that performs a specific action in the peripheral system - e.g., get_tariff_offer, send_offer_by_email or do_tariff_change.
  • Webhooks — Synchronous calls to peripheral systems, e.g., sending an email via API. Errors are reported directly to the user, the process waits for the response.
  • Event Hooks — Asynchronous reactions to Enneo-internal events (ticket created, answered, closed, …), for example, to export data or inform other systems. Errors are logged in the event trace, but not surfaced directly to the user.
  • User Defined Functions (UDFs) — Reusable code blocks, which can be centrally managed and called from any other points.

​
The two types of execution

Enneo supports two ways to execute custom code. The difference is not in the complexity of the code, but in who hosts and operates the code — Enneo or the peripheral system on its own infrastructure. In both cases, input and output data are passed as JSON.

​
Hosting by Enneo: Sandbox execution (type code)

The code is stored directly in Enneo and executed in the Enneo sandbox. Supported languages are PHP, Python and Node.js. Within the sandbox, the full Enneo SDK, any packages (via Composer, pip, npm) and access to input parameters, storage objects and all Enneo APIs are available. Input and output are JSON. Advantages:
  • No own server infrastructure, no deployment, no external accessibility needed.
  • Changes are effective immediately, without release process.
  • Direct access to the Enneo SDK and to Enneo APIs.
Restrictions:
  • No version control (Git) and only limited debugging.
  • Tests do not run in the usual CI setup of the own codebase.
Therefore, in practice, it’s best suited for simple, manageable logic.

​
Hosting by the peripheral system: Direct API call (type apiCall)

The code is operated on its own infrastructure as an HTTP endpoint. Enneo sends a request to the configured URL and continues with the response. The following are specified:
  • HTTP method (GET, POST, PUT, PATCH, DELETE)
  • URL
  • HTTP headers (authentication headers can refer to secrets)
Here too, input and output are JSON: With GET and DELETE, the input parameters are automatically appended as a query string to the URL, with POST, PUT and PATCH they are passed as a JSON body. The response is parsed as JSON and returned. Advantages:
  • Full control over source code, versioning, tests, deployment, and monitoring.
  • Integration into existing internal systems and tooling.
Restrictions:
  • Requires a separate server component that can be accessed from Enneo.
  • Each change goes through the own release process.