Zato: an enterprise service bus you configure through a browser

What the platform is for

Zato is a Python-based, open-source platform that lets you automate, integrate and orchestrate business systems, APIs, workflows as well as hardware assets. The tagline is ESB, SOA, API and Cloud Integrations in Python.

The industries the project names are the clearest statement of its scope: airports, defense, health care, telecommunications, financial services, and government. Those are the places where a flight departure system has to talk to a baggage system, or a hospital has to exchange HL7 messages with a lab, and where the protocols involved are old, varied, and not going to change.

The topic list reinforces it. Alongside the familiar esb, api-gateway, api-server, and orchestration-framework entries, there are aerospace, airport, defense, fhir, healthcare, hl7, interoperability, ipaas, and low-code. FHIR and HL7 are not the vocabulary of a general API tool, and the fact that they are in the topic list tells you the project is used in environments where those standards are mandatory rather than optional.

The project is AGPL-3.0 licensed, the primary language is Python, the home page is zato.io, the default branch is main, and the last push to the repository was on 2026-10-15. There are no GitHub releases, so the published distribution is the site itself, and the download documentation points at the install guide for the current 3.2 documentation line.

The service model, which is unusual for a Python platform

The example in the README is the best explanation of how Zato is written, and it is worth reading closely because the shape is not what you would expect from a platform with a graphical designer.

# Zato
from zato.server.service import Service

class RESTService(Service):

    def handle(self):

        # Request to send ..
        request = {'user_id':123, 'balance':1357, 'currency':'USD'}

        # .. get a connection to our previously created REST endpoint ..
        conn = self.out.rest['Billing'].conn

        # .. invoke it ..
        response = conn.post(self.cid, request)

        # .. and return the response to our caller.
        self.response.payload = response.data

The structure is: subclass Service, implement handle, look up a connection by name from self.out, invoke it, and put the result in self.response.payload. The connection is not constructed in the code, it is looked up by a name that refers to something created previously through the platform, which is what makes it an integration platform rather than a library.

The self.out.rest['Billing'] lookup is the key line. The name Billing refers to a REST endpoint that was configured, with its address, credentials, and behaviour, outside the code. The code refers to it by name, so moving the endpoint, rotating its credentials, or changing its timeout is a configuration change, and the service code does not move.

That is the design decision that makes Zato an ESB rather than a collection of integration scripts. The service is the unit of orchestration, and the connections are configuration, which is also why the project is described as low-code and API-first: the platform is where the wiring lives.

The test matrix is the real product catalogue

The Makefile in the repository is the most revealing document in it, because the list of test targets is effectively the list of protocols and systems the platform supports.

The messaging side covers the queue delivery tests for REST, SOAP, FHIR, and MLLP, plus the channel variants for REST and SOAP. The protocol tests cover EDIFACT and SOAP. The healthcare set includes HL7, CCDA, and documents, and there are named HL7 scenarios for health information exchange, registration, and lab.

Then there are the application protocol tests: MCP, bearer authentication, GraphQL, and gRPC. And the data source tests: SQL, Oracle DB, MSSQL DB, AWS, the SDK, Microsoft Cloud, Salesforce, and Discord.

And the infrastructure side: IBM MQ, Kafka, Kafka live, MongoDB, Elasticsearch, FTP, file transfer, the rule engine with a performance variant, and the fabric with a live variant.

Read as a whole, that is a platform that speaks the protocols of an enterprise integration team: HL7 v2 over MLLP, FHIR resources, EDIFACT, SOAP and WSDL, Kafka and IBM MQ, and a rule engine for transformation. The test naming convention is also consistent, since each target is a prefix such as test-queue-delivery or test-hl7, which means a CI system can run one protocol group or all of them.

The topics list names aerospace, airport, defense, and telecommunications, and the test matrix is consistent with that: MLLP and HL7 are the protocols of clinical and aviation systems, and Kafka and IBM MQ are the transports of logistics and defence telemetry.

Multiple processes, and why the Makefile builds them separately

The build targets make clear that Zato is not a single process, and that has real operational consequences.

There is a server build, a scheduler build, an io build, a common-core build, and a queue-bridge build, each with its own clean and install target, plus a health service with its own build and install, and a separate mq-client target. The runtime targets that mirror them are equally explicit: stop-server, restart-server, restart-server-with-scheduler, stop-dashboard, restart-dashboard, scheduler, queue-bridge, file-listener, and openapi-console.

The scheduler is the piece that makes sense only once you know the design. Zato is an event-driven platform, so there is a component whose job is to fire scheduled and queued work, and it is a separate process with its own health checks. The queue-bridge is the other half of that: it is the component that moves messages between Zato's own queue and an external broker such as Kafka or IBM MQ, and it is a separate process because that is where the reliability boundary sits.

The dashboard and the OpenAPI console are separate runtime targets too, which tells you the web interface is not a tab inside the server process.

Splitting the platform into a scheduler, a queue bridge, and a server is the right call for an ESB, since it means a stalled external broker does not take the request path down with it, and it means the scheduler can be scaled or restarted independently. It also means running Zato properly is an operations exercise rather than a pip install, which is worth knowing before you commit to it.

The Python project configuration, and what the test markers say

The pyproject.toml is short and tells you how the project is tested rather than how it is built, and the pytest configuration is where the interesting detail is.

Three custom markers are declared. The perftest marker is for long-running performance tests, skipped by default. The expect_log_errors marker is for tests that intentionally trigger server log errors matching given patterns, which is the mechanism for asserting that a failure path logs the right thing rather than just returning an error. And the slow marker covers tests that wait on the scheduler firing or move a lot of files, deselected with -m 'not slow'.

The addopts line combines them: -m 'not perftest' --import-mode=importlib, with log_cli enabled and the log level at DEBUG and a log format that includes the process id and thread name.

The thread name in that format is not incidental for a platform that runs services concurrently. The importlib import mode is also a deliberate choice, since it avoids the import-mode headaches that come with a test suite laid out in a way that does not match the package structure, and it is what allows the tests to import the components the way the running code does.

The filterwarnings list is a long one, and the comment above it explains the policy: only third-party warnings may be listed there, and anything the project's own code emits is fixed at the source instead. The suppressed items are all deprecations from dependencies, urllib3, pkg_resources, crypt, distutils, and the urllib3 insecure request warning, plus a note that an unverified HTTPS request is being made is allowed to pass.

Editorial conclusion

Adopt Zato if you need to wire together enterprise systems and protocols, especially healthcare or telecom, and you want configuration over code. Do not adopt it for a single internal API, where a library or a few scripts will do. Verify first which connector version your systems need, since the protocol support is broad but each integration has its own caveats, and the AGPL licence matters if you intend to modify it.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. zatosource/zato on GitHub