How Do You Connect an App to ARES, and How Are Czech Data Boxes Different?

ARES, the Administrative Register of Economic Subjects, is operated by the Ministry of Finance. According to the ministry, it provides a public API for searching for entities and their public data from source registers. Anyone who complies with its terms of operation may use the services.

For a business application, this means being able to find an entity by its IČO and use the returned data in a form or record. The specification should distinguish between finding a company and deciding whether you want to do business with it. The application should not present a matching record as a supplier recommendation or confirmation of its reliability.

The word “verified” therefore needs a specific meaning. Does it mean that the application found a matching entity, or that the user checked the data before saving it? If both situations use the same label, staff cannot tell what actually happened.

A sensible starting scope is to look up data when registering a customer or supplier. How the data will be used should then determine when it is refreshed and who may change the stored values. Without this decision, a correctly functioning integration can create uncertainty in the business process itself.

Before addressing the technical connection, you need to describe the path through the form. The user enters an IČO, the application requests the data and presents the result for review. The specification should also define what happens when the request fails, so that an error message is not the only way forward.

It is useful to distinguish between an entity that was not found, invalid input and an unavailable API. These are different situations with different next steps. When the service is unavailable, the application must not claim that the company does not exist, because a failed connection does not support that conclusion.

When designing the form, clarify:

• Which data should be filled in automatically and which the user should enter.
• Whether the user may continue before verification is complete.
• Who will later handle records awaiting verification.
• What should happen when newly retrieved data differs from the stored values.

Allowing users to continue manually is not appropriate for every process. If the next step depends on verified data, the right solution may be a draft record and a clear notice that verification is pending. The important point is that the application must not hide an uncertain result behind a success message.

Public access to ARES does not mean unlimited use. According to the ARES terms of operation on the Ministry of Finance website, the ministry reserves the right to restrict or disable access, including when a user makes more than 500 requests per minute. Repeated identical or incorrectly completed requests and a large number of simultaneous requests may also lead to restrictions.

The terms also mention circumventing limits through multiple IP addresses and automatically searching the database with random data. The stated threshold therefore cannot be treated as a recommended operating rate below which any behaviour is acceptable. The design must account for all the terms, not just the request counter.

Caching means temporarily storing a result so that the application does not have to contact ARES whenever the same record is opened. The appropriate retention period depends on the purpose of the data. Prefilling a form that is still in progress may have different requirements from checking the data again before a subsequent business decision.

The design should also limit concurrent requests and validate input before sending it. Bulk processing should use a queue to spread the work over time. According to the ministry’s terms, restoring restricted access requires sufficient written assurances agreed with the Ministry of Finance, so relying on access being restored later is not an operating plan.

The specification needs to cover outages as thoroughly as successful retrieval. A form in progress should preserve the user’s input and explain whether they can continue or need to wait. If the application uses stored data, it should make clear that no new verification has just been completed.

Retrying a request can help during temporary unavailability, but it needs rules. Constantly repeating the same request immediately would defeat the purpose of traffic control. The design should specify when the next attempt will occur, when automatic attempts will stop and who will see the unresolved status.

The Ministry of Finance publishes an ARES API changelog, and the API changes over time, including backward-incompatible changes. Integration maintenance therefore needs to be part of project planning before launch. It should have an assigned owner and a process for verification after a change.

Application acceptance testing should cover a successful lookup, an entity that was not found, service unavailability and an unexpected response. The checks should also cover what the user sees and what record remains stored. Knowing that the application connected successfully is not enough to confirm that the entire process works correctly.

According to the ISDS API documentation, external applications can use web services over HTTPS. An application can authenticate using a certificate. Connecting your own data box therefore adds access to the box and handling communications to the specification, requiring different decisions from looking up a public record.

For incoming messages, you need to determine who will bring the message into the company process and how they will know that it requires their attention. For outgoing messages, it must be clear who approves the content, the recipient and the act of sending. These roles should be described before the application screens.

The specification should distinguish between preparing a message, attempting to send it and receiving a confirmed communication result. If the result of a request is unclear, automatic retries must not be a reflexive response. The required procedure needs to be designed for the specific operation and its possible consequences.

The technical transmission status does not replace a legal assessment of delivery. We recommend discussing the legal effects and allocation of responsibility with a lawyer based on your use case. This article describes questions for application design, not the legal rules governing delivery.

We use ARES in our own product Innea Pro to verify companies by IČO during registration. Innea Pro is an operations system for Czech therapists. It is our own product and an example of the integration in production.

We build integrations with data boxes, registr smluv (the public contract register) and NEN (the national e-procurement platform) to order based on the specification. We do not yet have integrations with these systems in a product we operate, so we cannot provide a running product as evidence. We do not present our experience with ARES as proof of those integrations.

When making an enquiry, it helps to describe where the IČO comes from, what should happen after verification and what may happen when the service is unavailable. For a data box, also include the expected receipt and sending of messages and the people responsible for each step. This specification makes it possible to separate the integration itself from changes to the company process.

We work AI-native: delivery is accelerated with Claude Code and Codex, and quality is secured by automated tests, independent code review and specialists on demand.

1. Do we need to create an account for ARES?

   The public ARES API does not require authentication. According to the Ministry of Finance, anyone may use the services if they comply with the terms of operation. Access to your own data box works differently and requires authentication.

2. Can a customer complete registration if ARES does not respond?

   Your application specification should determine this based on the purpose of the verification. Options include keeping the registration as a draft or continuing with a clear pending-verification status. Service unavailability must not be mistaken for confirmation that the data is correct.

3. Should we verify a customer's company again every time they sign in?

   The frequency of checks should be based on how the data is used, not automatically tied to signing in. Repeatedly retrieving the same record may be unnecessary, and the ARES terms explicitly mention repeated identical requests. The design should therefore include rules for refreshing stored results.

4. Will you deliver a complete module for receiving and sending data-box messages?

   We offer two-way integration as custom development. We cannot yet provide a complete module verified in a product we operate. The scope must also cover permissions, approvals and handling an unclear communication result.