Adeo POS API - Adeo POS International

Adeo POS API — questions and answers

Choose a topic or find an answer for your integration, from the first API call to the service model and support.

20 questions to get started

What is Adeo POS and who is it for?
Can we keep our existing application and use only the API?
Which Adeo POS API does our project need?
Does HTTP 200 mean that an invoice has been successfully fiscalized?
How do we receive the result, and what if the callback does not arrive?
What is ExternalID and when should we assign it?
How do we avoid duplicate invoices after a retry or timeout?
What happens if the tax or fiscal service is temporarily unavailable?
Can the cloud API work without internet access?
Can one SaaS integration serve multiple legal entities?
Can we connect our existing online store to Adeo POS?
Can we keep our payment gateway and existing payout arrangements?
Can we obtain a PDF with a QR code or create our own invoice layout?
Does Adeo POS automatically email the invoice to the customer?
Can we send e-invoices from our own ERP system?
Can a vending or self-service system use the cloud API?
Can we use Adeo POS in multiple markets?
Who onboards new customers?
How is API integration pricing determined?
What support is available during integration?

Overview and markets

What is Adeo POS and who is it for?

Adeo POS connects invoicing, fiscalization, e-invoicing and business applications. It can be used as a POS solution or through an API in an online store, ERP system, SaaS platform, mobile app or self-service system. Available features depend on the product and market.

Can we keep our existing application and use only the API?

Yes. Your application, online store or ERP system can remain the main user interface while Adeo POS handles fiscalization and other agreed processes through the API. The integration scope determines which data and statuses your application needs to send, receive and display.

Can an integration cover consumers, businesses and public bodies?

A project can cover different customer and document types. When choosing the API, distinguish invoice fiscalization from sending and receiving e-invoices, and confirm the supported workflow for each market and document type.

What does fiscalization mean in an API integration?

Fiscalization is the electronic submission of invoice or receipt data to the relevant fiscal system. An API integration connects your application to that processing and lets it track the result. Data requirements, identifiers and workflows differ between countries.

What does Adeo POS process and what results does it return?

Adeo POS receives invoice data, processes it and communicates with the relevant fiscal system. The integration then retrieves the status, result or error details. JIR and ZKI are Croatian fiscal identifiers used in the applicable Croatian workflows; they are not universal identifiers for every market.

Which Adeo POS API does our project need?

FiskalQ handles invoice issuance and fiscalization, including supported e-invoice issuance workflows. The ADEO business API covers business data and operations, while a separate e-invoicing API covers other e-invoice processing workflows. The required interfaces depend on the full workflow, not just on whether an invoice needs to be issued.

Can we use Adeo POS in multiple markets?

Adeo POS is used in multiple markets, including Croatia, Montenegro, Serbia, Slovenia and the Czech Republic. An existing integration can provide a starting point for expansion, but product availability, required fields and local workflows must be checked for each country. Do not assume that the same request can be used in every market without changes.

What does Adeo POS provide compared with a direct fiscal-system integration?

Adeo POS handles the agreed communication and processing layer for the fiscal system, instead of your team building it separately for each integration. Your team still designs the business workflow, sends correct data and handles statuses. Responsibilities and maintenance scope are defined as part of the agreement.

API integration and statuses

Which format and communication method does the API use?

The request format, authentication and available operations are defined by the documentation for the selected API and version. Request the appropriate specification and examples before development. Do not assume that different Adeo POS APIs use identical fields or access methods.

Is the cloud fiscalization API synchronous or asynchronous?

Cloud FiskalQ uses asynchronous processing: the application submits a request and retrieves the final result later. This means communication with an external fiscal system does not have to block the application's entire workflow. Other APIs and local components must be assessed separately.

Does HTTP 200 mean that an invoice has been successfully fiscalized?

No. In the cloud invoice queue workflow, the initial HTTP 200 confirms that the request has been received for processing. Business validation and the fiscal result follow later, so the integration must check the status or process the callback. A successful HTTP response does not confirm that all data is valid or that fiscalization is complete.

How do we receive the result, and what if the callback does not arrive?

Depending on the integration, you can receive the result through a callback or retrieve it later through the status API. If a callback does not arrive, check the existing transaction instead of immediately issuing a new invoice. Use the polling frequency, status names and callback rules defined for the relevant API version.

What is ExternalID and when should we assign it?

ExternalID is the invoice identifier supplied by your system. Assign it before the first submission and keep it linked to the business document so you can track the result and retry the same request. Use a stable identifier that is unique within the agreed integration scope; confirm the exact uniqueness scope and permitted format in the specification.

How do we avoid duplicate invoices after a retry or timeout?

Keep the same ExternalID for the same business event and check the existing transaction first. If resubmission is needed, do not create a new identifier just because a response was not received. Duplicate protection depends on correct identifier use; correcting the contents of an already accepted invoice is a separate workflow defined by the specification.

How should we handle the same callback more than once?

Design callback handling so that a repeated notification for the same transaction only reconciles its status. It should not trigger payment, invoice issuance or fulfilment again. This is an application design rule, not an assumption about a guaranteed number of callback deliveries.

How should we plan a high-volume integration?

Provide the expected monthly volume, peak traffic, number of users and devices, and required processing times. These inputs are used to agree technical and commercial terms. Confirm specific limits, API call frequency and load testing for your project.

How do we obtain documentation and test access?

Describe your business scenario and request documentation and test access for the required API. Develop and validate the integration in the test environment before enabling production settings. Business API documentation does not replace the documentation for FiskalQ, e-invoicing or App2App.

Who builds the integration and what needs to be implemented?

Your development team or application provider normally builds the integration using the relevant specification. The basic scope includes preparing invoice data, managing identifiers, submitting requests, tracking statuses and handling errors. Adeo POS support and any additional development are agreed separately.

Who controls invoice numbering?

Responsibility for assigning numbers and transferring numbering information must be defined for the selected product and market. Agree on business locations, cash registers and numbering rules before development. ExternalID links a transaction to your system and should not automatically be treated as the fiscal invoice number.

Can one invoice contain items with different VAT rates?

Yes, the described API workflow supports items with different VAT rates. The rates, amounts and calculation method must match the market and integration specification. Include mixed VAT rates and total calculations in your tests.

Reliability and error handling

What happens if the tax or fiscal service is temporarily unavailable?

Cloud processing uses a queue and automatic communication retries towards the fiscal service for temporary communication problems. Your application must track the final status. Incorrect data or an invalid certificate requires separate action; retries do not guarantee that every request will succeed or continue indefinitely.

What if our application cannot reach Adeo POS?

Keep the business transaction and its ExternalID in your own system. When connectivity returns, check whether the request was already received and continue using the rules for that same transaction. The Adeo POS queue towards the fiscal service does not replace storage of requests that have not yet reached Adeo POS.

What if we lose connectivity after submission and do not know whether the request was accepted?

A lost connection does not prove that the request was not received. Keep the existing ExternalID and check the transaction using the available status API workflow. If the outcome is still unclear, contact support before trying to issue a new invoice for the same event.

Does FiscalizationErrorCode 900 mean that the invoice was not fiscalized?

The code alone is not enough to determine that. In a documented case, the invoice had been fiscalized but a communication problem prevented the result from reaching FiskalQ. Check the specific transaction and involve support if needed; do not automatically issue a new invoice or assume that every code 900 has the same cause.

What information should we send support when a status is unclear?

Provide the ExternalID, request time and time zone, test or production environment, API version, and the status or error code received. Include a request and response example with passwords, tokens, private keys and unnecessary personal data removed. State whether the request was retried and whether a callback was received.

E-commerce, payments and documents

Can we connect our existing online store to Adeo POS?

Yes, if the store or its developer can implement the required API calls and status handling. The existing store can remain the sales interface while Adeo POS handles invoices and other agreed processes. Availability of a ready-made plugin for a particular platform must be checked separately.

Can we keep our payment gateway and existing payout arrangements?

Yes. Payment collection and fund distribution can remain with your payment provider while Adeo POS processes the invoice. This also applies to platform payment architectures, but does not by itself mean that a ready-made connector exists for a particular provider. The integration must clearly link the payment, seller and invoice.

Can a confirmed payment automatically trigger invoice issuance?

Yes. One possible integration workflow is for the application to submit invoice data after payment confirmation and track processing afterwards. When an invoice must be issued and what must be shown to the customer depends on the business model and market. An asynchronous API does not itself determine the permitted timing of invoice issuance or fulfilment.

Can we obtain a PDF with a QR code or create our own invoice layout?

In the supported workflow, Adeo POS generates an invoice PDF with a QR code, and the integrator can provide a document link to the customer. You can also create your own document layout using the invoice data and fiscal result. Confirm the retrieval method, document identifier and QR code contents for the selected API and market.

Does Adeo POS automatically email the invoice to the customer?

Generating a PDF does not automatically include email delivery. In a typical integration, your application sends its own message with a link to the invoice. If you want Adeo POS to send the message, delivery, the email template and any additional development must be explicitly included in the project scope.

Can we edit the email template used by Adeo POS ourselves?

A self-service template editor is not automatically included in an API integration. Sending messages with an agreed template and providing a tool to edit that template are separate requirements. If you need this capability, include it when agreeing additional development.

How do we connect products, prices, stock and business partners?

This belongs to the business API scope and should be defined separately from fiscalization itself. Confirm the available operations in the documentation and decide which system owns each data set. The ERP system or online store can remain the primary data source; do not assume that every requested endpoint is already available.

Is sending an order to a POS the same as integrating fiscalization?

No. An order has its own acceptance, rejection, amendment, cancellation and customer notification workflow. Invoice fiscalization may be one step in that process. Required order statuses and available operations must be defined separately; an invoice API does not imply a complete order management system.

Are cancelling an invoice and refunding a payment the same operation?

No. Correcting or cancelling a fiscal document and refunding money through a payment provider are separate operations that your application needs to link. Before development, confirm the supported document types, reference to the original invoice and partial-refund handling. The exact API call and treatment of an invoice without a final result depend on the specification.

SaaS, partners and onboarding

Can one SaaS integration serve multiple legal entities?

Yes. One platform integration can process invoices for multiple legal entities, with separate fiscal and organisational settings for each customer. In Croatia, these include the customer's OIB tax identifier. A new customer is added through onboarding and configuration rather than by building the integration again from scratch.

How should a marketplace or franchise model be designed?

First establish who sells, who issues the invoice and which entity owns each transaction. A central application can connect multiple entities, but their invoices and fiscal settings must be correctly separated. Commissions, vouchers and collecting payments on behalf of others require their own defined business workflows.

What is the difference between clientCode and OIB?

In the described partner workflow, clientCode identifies the integrator, while OIB identifies the Croatian legal entity for which the invoice is processed. They are not interchangeable, and one clientCode does not necessarily mean one invoice issuer. Configure access and the associated entities during onboarding.

Does the fiscalization API automatically include customer creation and certificate management?

Do not assume that it does. Creating legal entities, locations, cash registers and operators, and uploading or replacing certificates are separate administrative tasks. Available API operations and any required extensions must be confirmed for your onboarding model.

Who onboards new customers?

Onboarding can be organised with Adeo POS or through a trained partner. Correct business and fiscal data must be collected, responsibility for entering and maintaining settings must be agreed, and initial operation must be checked. Timing depends on data readiness and the required configuration.

Is there a partner model for software companies?

Yes. A partnership can cover integrating the Adeo POS service into your product and offering it to end customers. The agreement defines commercial terms, onboarding, billing and support responsibilities. The specific model depends on the partner's role.

Who contracts with the end customer?

This depends on the partnership model. Customers may contract directly with Adeo POS, or the relationship may be managed through a central partner agreement. Agree on the contracting party, billing arrangements and support responsibilities before onboarding customers.

Can we have a central partner portal?

Central administration should be defined around the tasks the partner needs to perform, such as onboarding customers, reviewing settings, monitoring operation or billing. It is not automatically included in the invoice issuance API. Available tools and any development needed are assessed as a separate scope.

Who supports a partner's end customers?

Support can be provided by the partner or Adeo POS, depending on the agreement. Define first-line support, escalation of technical issues and communication with the end customer. This division of responsibilities also affects the partnership terms.

Can we start with one customer and add more later?

Yes, a project can be introduced gradually. If you plan to support multiple legal entities, separate their settings and identifiers from the start and clearly link every invoice to its issuer. This avoids redesigning an integration that was built only for one customer.

E-invoicing and archiving

Can we send e-invoices from our own ERP system?

Yes. E-invoice issuance can be included in an integration with your own application or ERP system. Select the appropriate API, supported document type and market when defining the project. Document submission and its subsequent statuses should form part of the agreed workflow.

Is receiving e-invoices the same process as sending them?

No. Incoming and outgoing documents have different processing workflows. If you need to retrieve and process incoming e-invoices, include that scope and the relevant e-invoicing API in the project. Integrating issuance through FiskalQ does not mean that the entire incoming-document workflow is covered.

How do we track an e-invoice's status?

Include retrieval and handling of the statuses exposed by the selected e-invoicing API. Confirm what each status means for document submission, delivery and subsequent processing. Do not assume that technical acceptance automatically means all later steps are complete or that the invoice has been paid.

Can we add e-invoicing in a later project phase?

Yes, the technical project scope can be divided into phases. It is useful to plan the required APIs and future incoming and outgoing document workflows in advance. The rollout sequence must fit your business needs and the obligations in your market.

Devices, Android and offline operation

Can the cloud API work without internet access?

Submitting a request to the cloud API requires a network connection. Offline operation needs a separately designed local storage workflow and a component suited to the device and market. A cloud queue towards the tax service is not the same as offline operation on your device; the local workflow and subsequent processing must be checked for the specific product.

Can a vending or self-service system use the cloud API?

Yes. A vending or other self-service system can connect its application to the Adeo POS cloud API without a conventional POS interface. A central platform can submit invoices for multiple devices, with correct identification of the device, sales point and issuer. Suitable connectivity and market-specific configuration are required.

How should we design a vending system with intermittent connectivity?

First define what the device is allowed and able to do during an outage, and where it stores the transaction and identifiers. Local fiscal processing, later submission and the customer display must be confirmed for the specific device and market. Do not assume that the cloud API alone provides a ready-made offline service.

Is there an Android POS application with App2App integration?

Yes. Adeo POS has an Android POS application with fiscal processing and an existing App2App workflow for receiving invoice data from another application. Confirm the user workflow and supported devices for the application version. App2App availability does not automatically mean that an invoice can be completed without user interaction.

Does a cloud-connected device need to store the fiscal certificate locally?

In the described cloud workflow, the fiscal certificate is stored and used within the Adeo POS system, while the customer provides a valid certificate. This does not automatically describe a local or offline architecture. Define the required certificates, secure delivery method and renewal responsibilities for the relevant market and project.

Pricing, support and getting started

How is API integration pricing determined?

Pricing depends on the product, market, number of legal entities, cash registers or devices, document volume and support needs. POS, web cash register, vending and partner projects do not necessarily use the same billing model. Provide the expected scope for a quotation; do not assume that every invoice is billed separately or that every API is included in an existing licence.

How are subscription terms and initial fees agreed?

The quotation should state the billing period, included licences or documents, initial setup and integration support. Monthly or annual terms depend on the product and market. One-off costs and additional development should be clearly separated from the recurring subscription.

Are special terms available for partners or larger customer bases?

Partner terms can be agreed based on the product, number of active customers or cash registers, volume and the partner's support role. A discount or price in an individual quotation is not a universal term for every project. Your quotation and agreement define the exact model and billing rules.

What should we prepare to get started?

Describe your application, countries, invoice issuers, payment methods and required document types. Include the number of legal entities and devices, expected volume, offline needs, and whether you need only issuance or also incoming e-invoices and business data. These inputs help determine the APIs, documentation, testing and quotation.

How long does integration take?

Timing depends on scope, data readiness, development team availability and test results. Basic invoice submission differs from a project involving multiple markets, customers, e-invoicing and offline operation. An estimate is made after requirements are defined; the time needed to enter a customer's settings is not the development time for the whole integration.

What support is available during integration?

Technical support and consulting scope depend on the APIs used and the agreed service model. Agree on the contact point, issue reporting process and integration review before production. Include successful and failed requests, retries, lost responses and correct separation of legal entities in your tests.

Can we migrate gradually from another fiscalization service?

Migration can be planned through development and testing of the new integration layer followed by a phased customer rollout. Pay particular attention to numbering, identifiers, pending transactions and the cutover point. Parallel testing does not mean submitting the same live transaction to two production systems.

Does an existing POS licence cover a new web cash register?

Do not assume that it does. A web cash register or a new API project may have a separate licence model and integration support fee. Check the existing agreement and confirm the scope before enabling the new service.

Does volume-based billing include incoming and outgoing documents?

The billing unit depends on the agreed model. A partner model may include both incoming and outgoing documents. The quotation should explicitly define what is counted and how cancellations, duplicates and failed attempts are treated.

Does integration support include developing new features?

Support for an existing API and development of new endpoints, templates or user tools are different scopes. Additional development, testing and maintenance must be agreed separately. One support fee does not automatically cover every API or unlimited customisation.

Basic

Standard

Hospitality

Adeo POS devices

Adeo KDS

Order Express