Custom Code in enneo

Enneo can be extended in many places with custom code by the client. This allows for the connection of external systems, capturing business logic, and implementing automations without altering the platform itself.

Where custom code is used in enneo

Custom code is always deposited in enneo as a so-called Executor and referenced at various points. Typical areas of application:

Customer Recognition — Searching by contract number, customer number, attributes or free text retrieves data from ERP or other source systems using custom functions.
Rule-Based AI Agents — The business logic of an agent (e.g., capturing meter readings, recording address changes, cancelling contracts) calls custom code to perform the actual action in the external system.
AI Tools for Smart AI Agents — Smart (LLM-based) agents autonomously decide which tool to call during a conversation. Each user-defined tool (managed under AI Customization → AI Tools) is an Executor that performs a specific action in the external system — e.g. get_tariff_offer, send_offer_by_email, or do_tariff_change.
Webhooks — Synchronous calls to external systems, e.g. sending an email via API. Errors are reported directly back to the user, and the process waits for the response.
Event Hooks — Asynchronous reactions to internal enneo events (ticket created, answered, closed, …) to export data or notify other systems. Errors are logged in the Event Trace but not directly surfaced to the user.
User Defined Functions (UDFs) — Reusable code components that are managed centrally and can be called from any other location.

The two types of execution

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

Enneo Hosting: 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 in JSON.

Advantages:

No need for own server infrastructure nor external accessibility, no deployment necessary.
Changes take effect immediately, without any release process.
Direct access to the enneo SDK and enneo APIs.

Limitations:

No version control (Git) and limited debugging.
Tests do not run within the usual CI setup of your own code base.

Therefore, it's best suited for simple, manageable logic in practice.

Hosting by the External System: Direct API Call (type `apiCall`)

The code is operated on the own infrastructure as an HTTP endpoint. Enneo sends a request to the configured URL and continues with the response. The following information is provided:

HTTP method (GET, POST, PUT, PATCH, DELETE)
URL
HTTP headers (Authentication headers can refer to Secrets)

Here too, input and output are JSON: For GET and DELETE, the input parameters are automatically appended to the URL as a query string, and for POST, PUT, and PATCH they are passed as a JSON body. The response is parsed as JSON and returned.