Choose the exchange pattern
A real-time application programming interface (API) suits interactive operations. An event or webhook announces change. Scheduled synchronization handles delayed batches. File import and export can suit manual control or systems without APIs. One solution often uses several patterns.
System of record, identifiers, and duplicates
For every object, name the system of record, definition owner, technical identifier, and business key. Define cardinality, duplicate detection, and conflict authority. Do not base identity on a mutable field such as email without explicit analysis.
Retries, idempotency, and reconciliation
A retry must not create a second business effect; this property is idempotency. Define attempt limits, backoff, dead-letter handling, alerts, and manual replay. Regular reconciliation should detect missing, duplicate, and divergent records independently of transport logs.
Secrets, observability, and outages
Credentials need minimal scope, secure storage, rotation, and ownership. Measure latency, errors, backlog, and business outcome. For each outage, decide whether processing stops, buffers, degrades, or becomes manual, and define recovery.
Named systems require connector-specific proof
The reviewed public code does not establish shipped connectors for KSeF, Comarch Optima, enova365, Symfonia, BaseLinker, or Allegro. Their status remains unknown for this guide. A public vendor API may make custom integration feasible, but scope, permissions, limits, certification, and testing need separate assessment.
Request and response API
Immediate command or lookup
Failure risk: Timeouts, partial writes, coupling
Event or webhook
Asynchronous notification and fan-out
Failure risk: Duplicates, ordering, retries, dead letters
Scheduled synchronization
Batch exchange with reconciliation
Failure risk: Drift, overlapping runs, stale data
File import or export
Controlled bulk exchange and cutover
Failure risk: Schema drift, encoding, replay and ownership
| Topic | Status | Evidence boundary |
|---|---|---|
| KSeF | unknown | A provider API does not prove an Open Mercato connector. |
| Comarch Optima | unknown | A provider API does not prove an Open Mercato connector. |
| enova365 | unknown | A provider API does not prove an Open Mercato connector. |
| Symfonia | unknown | A provider API does not prove an Open Mercato connector. |
| BaseLinker | unknown | A provider API does not prove an Open Mercato connector. |
| Allegro | unknown | A provider API does not prove an Open Mercato connector. |
Method, assumptions and limitations
Reviewed 14 July 2026. Product facts were checked against both the public code at the cited repository revision and official documentation. Where documentation and code differ, this guide describes behavior supported by code. Interpretations and recommendations concern implementation work, not product guarantees.
This material is not a quote, audit, certification, or legal, tax, or accounting advice. Edition, enabled modules, configuration, custom code, infrastructure, data, third-party providers, and operating practices affect the outcome.
Primary source collections: code repository, documentation, public releases.
Submit a correction with the public source and the date checked.