Connecting ERP, billing and third-party systems to epilot

An epilot integration links the platform to the systems a utility or grid operator already runs: ERP and billing, grid systems, other CRMs and in-house databases. If you want to connect those surrounding systems, you have more than one route. This article covers the routes epilot provides itself, when dedicated middleware is the better fit, and what matters for data ownership, error handling and operation.

I am Marcel R. G. Berger, a software developer and architect with more than 20 years of experience. I work with epilot as an external consultant and developer for apps and customisations. This piece is written for IT leads at grid operators, municipal utilities and energy suppliers.

What are the routes for an epilot integration with other systems?

There are two basic routes: the integration tools epilot ships with, and custom-built interfaces that sit between epilot and another system. Many projects end up using both.

epilot is an excellent no-code and low-code platform, and that extends to integration. The integrations overview in the epilot developer documentation lists several ready-made building blocks, each aimed at a different job.

A custom interface comes in when those building blocks are not enough on their own. That is not a weakness of the platform. Usually it means part of the process lives in other systems and is meant to stay there.

What does epilot provide for integration out of the box?

According to its developer documentation, epilot offers five integration routes: the Integration Toolkit, the Batch API, 3rd Party Journeys, webhooks and public APIs. Each one is designed for a different purpose.

Integration Toolkit for ERP systems

The Integration Toolkit is epilot’s building block for connecting ERP systems. The documentation describes standardised entity and event schemas, mappings based on JSONata and a dedicated inbound API through which ERP data arrives in epilot.

In the other direction, the documentation says epilot events reach the ERP through webhooks or pull-based polling. On top of that there is central monitoring: every event the toolkit processes is recorded as a monitoring event, with tracing, replay and alerting.

Batch API for many calls at once

The Batch API lets you run several epilot API calls in a single HTTP request. The documentation sets a limit of 100 requests per batch.

Individual failures do not affect the other requests in the same batch, and failed tasks are retried up to three times before they are marked as permanently failed. epilot recommends the Batch API for bulk upserts from middleware and for environments where every single HTTP request counts against a message quota.

Webhooks for real-time events

Webhooks in epilot let you subscribe to events in your account. When an event occurs, epilot sends an HTTP POST to the URL you configured. The available events are described on the core events page, and custom events can be defined on your own attributes.

For security, the webhook security documentation lists API key, basic auth and OAuth, plus signatures carried in the webhook-id, webhook-timestamp and webhook-signature headers.

Public APIs and 3rd Party Journeys

The epilot public APIs give direct access to the platform’s capabilities. The overview mentions more than 50 REST APIs, including Entity, Workflow, Document and Billing, each with a TypeScript client. Every request needs a bearer token. How a dedicated interface delivers data from other systems through these routes is covered in providing data via the epilot API.

According to the overview, 3rd Party Journeys are meant for submitting data from external forms and frontends. For connecting back-office systems they usually play a smaller part.

When is one of epilot’s own tools enough?

A built-in tool is enough when the job matches what it was built for and the logic in between stays manageable. In that case it is almost always the faster route and the one with less maintenance.

A few typical cases:

• An ERP system needs to sync contracts, meter readings or customer data with epilot, and the mapping can be described cleanly in the Integration Toolkit. The documentation lists exactly these flows as toolkit use cases.
• Existing middleware needs to write a large number of records to epilot in one go. That is what the Batch API is for.
• An external service needs to know that something changed in epilot and only needs the event data. A webhook does that directly.

The general rule: whatever can be configured cleanly in epilot should stay there. I explain why in more depth in when low-code in epilot is no longer enough.

When does an epilot interface need dedicated middleware?

An epilot interface needs dedicated middleware when a process spans several systems and the logic in between is more than mapping fields. The middleware is then a service of its own that receives events, translates data and triggers actions in other systems.

The signals are usually the same:

• A large part of a process runs outside epilot, in a line-of-business system that stays in use.
• A surrounding system has no ready-made connection to epilot and speaks its own format or interface.
• Data comes from several sources and has to be merged, checked or enriched before it moves on.
• An event in epilot should start a chain: an event in another system, a response, and finally information written back to epilot.

I build these services as mappers in Java with Quarkus, running in containers, scalable and maintainable. How such a mapper is put together and which rules keep it stable in operation is covered in mappers between epilot and surrounding systems with Quarkus.

One point matters here: middleware does not replace the built-in tools. It uses them. A mapper typically receives webhooks from epilot and writes back through the public APIs or the Batch API.

Which integration route fits which requirement?

The right answer follows from where the logic lives and how many systems are involved. The table below sorts the most common requirements.

Requirement	Obvious route	When dedicated middleware comes in
Sync ERP data with epilot	Integration Toolkit	when further systems or rules outside the ERP are involved
Write many records at once	Batch API	when the data first has to be assembled from several sources
Notify an external service about events	Webhook	when the event should trigger a chain in other systems
Own application reads and writes epilot data	Public APIs	when load, retries and logging need logic of their own
Take over data from external forms	3rd Party Journeys	rarely needed
System without a ready-made connection	Public APIs and webhooks	usually as a dedicated mapper
Process runs mostly outside epilot	Webhooks as the trigger	a mapper that drives the process across system boundaries

Treat the table as orientation, not a fixed rule. In practice, the conversation about your actual systems decides.

Which surrounding systems are typically connected?

Four groups of systems come up again and again: ERP and billing, grid systems and line-of-business applications, other CRMs, and in-house databases with master or historical data. Each group brings different requirements.

ERP and billing

ERP and billing systems are often the owner of contracts, customer numbers and anything to do with money. epilot’s Integration Toolkit is explicitly designed for this group. Custom development comes in when workflows reach beyond the ERP or data has to be enriched first.

Grid systems and line-of-business applications

Grid operators rely on specialist applications that are closely tied to technical processes. These systems usually stay in place and have interfaces of their own. A custom connection is often the only clean way to link them.

Other CRMs

Not every company moves every area to epilot at the same time. When another CRM runs in parallel, contacts and cases have to be synced in both directions without creating duplicates.

In-house databases with master or historical data

Many companies keep databases with master data or historical records that are not meant to move to epilot in full. An interface can query that data on demand and provide the relevant information in epilot.

Which system owns which data?

For every type of data, it has to be clear which system creates and changes it and which systems only read it. That decision matters more than any technical choice, because without it systems overwrite each other.

A simple overview per data type helps: owning system, reading systems, sync direction and trigger. An example of the thinking: if the billing system owns customer numbers, epilot does not issue its own but takes them over.

Clear rules for the interface follow from this. It only writes in the agreed direction, and it detects conflicts instead of quietly resolving them. For grid operators with regulatory obligations, that traceability matters a great deal.

How do you handle errors and load?

A good integration handles errors and load deliberately: with retries, idempotency, logging and monitoring. Every network drops out now and then, and every API has limits.

The rate limits page in the epilot documentation states that the API answers with HTTP 429 once a limit is exceeded and uses the Retry-After header to say how many seconds remain until the quota resets. For large data volumes, epilot points to the Batch API and the ERP Integration API.

On the epilot side, webhook monitoring helps. According to the documentation, every webhook request is logged as an event with a success or failure status, kept for four weeks by default, and can be replayed.

Inside your own middleware, that means:

• retries with backoff that respect Retry-After
• idempotency, so an event delivered twice does not create a duplicate record
• a log with a unique identifier per message across all systems
• monitoring that raises an alert when a connection stalls

Who runs the integration later on?

Either your own team runs the integration or I look after it under a maintenance contract. Both work, because the code belongs to you.

On request, I hand the code over to your own repository. Your team can then develop and run the interfaces independently. Why this question matters so much for grid operators is explained in who owns the integration code.

Data stays in Europe, processing follows the GDPR, and a data processing agreement is signed where required. The contracting party is DigitalFreedom Global LLC; German law is available on request for grid operators. Details are in the contracting party section on the home page.

What does this look like at a grid operator?

At a grid operator in Hesse, many processes run outside epilot, and several third-party systems are connected through individually developed interfaces. The company’s name stays confidential.

For these connections I developed individual mapper tools in Java with Quarkus. They run in containers and are scalable and maintainable. Typical jobs for mappers like these include webhooks, REST calls to surrounding systems, triggering events in other systems and providing information in epilot.

The example shows the usual split. epilot remains the platform for customer processes and configuration, while the mappers handle the logic between systems. More background is in the in practice section on the home page.

I work together with epilot and complement its consulting team rather than replace it. For the rollout and the standard scope, epilot remains your point of contact.

How do you get started connecting your systems?

You start with a free intro call in which we go through your systems and workflows. Afterwards it is clear which of epilot’s own tools are enough and where a custom interface makes sense.

1. Intro call: free and without obligation, 30 minutes on Microsoft Teams.
2. Individual quote: tailored to your surrounding systems, data formats and operational requirements.
3. Delivery: the interfaces are built, tested and put into operation with your systems.

Everything I offer is based on an individual quote. Invoicing is in euros, EU business clients are invoiced under the reverse charge mechanism after a VIES check of their VAT number, and professional liability insurance is in place. More answers are in the frequently asked questions on the home page, and you can pick a slot directly in the booking calendar.