{"id":71972,"date":"2026-08-21T09:00:00","date_gmt":"2026-08-21T07:00:00","guid":{"rendered":"https:\/\/symmy.com\/erpedie\/co-je-integracni-platforma-2\/"},"modified":"2026-08-21T09:00:00","modified_gmt":"2026-08-21T07:00:00","slug":"co-je-integracni-platforma","status":"publish","type":"erpedie","link":"https:\/\/symmy.com\/en\/erpedie\/co-je-integracni-platforma\/","title":{"rendered":"What is an integration platform \u2014 and when you need one instead of a bridge"},"content":{"rendered":"<p>\u201cIs a simple bridge enough, or do we need an integration platform?\u201d The term <em>integration platform<\/em> shows up in vendor offers and means something different every time \u2014 from an e-shop add-on to an enterprise service bus costing millions. This article compares both approaches without the sales fog: what an integration platform really is, when it is overkill and how to tell the moment has come.<\/p>\n<h2>The short answer<\/h2>\n<div class=\"ep-answer\">\n<p><strong>An integration platform is a separate layer between your systems<\/strong> that handles data transfer, transformation and monitoring in one place \u2014 one log, one dashboard, any number of connected systems. <strong>A bridge is a single-purpose connection between two specific systems<\/strong> with a fixed scenario. For one data flow between two systems a bridge is cheaper and faster; once you run three or more systems, need to transform data on the way or your operations depend on the transfers, a platform is more reliable and cheaper to manage.<\/p>\n<\/div>\n<h2>A bridge: the shortest path between two systems<\/h2>\n<p>A bridge (connector, add-on) links exactly two systems in exactly one scenario \u2014 typically orders from the e-shop into the ERP and stock levels back. Field mapping is fixed, deployment is quick and the price is low; for standard pairs it is often offered by the e-shop or ERP vendor themselves. That is its strength and its limit: what it does is all it does. A change in mapping or a new requirement means a vendor request \u2014 and every additional bridge in the company is another separate thing to manage, with its own vendor, its own behaviour on errors and its own (often non-existent) logs.<\/p>\n<h2>An integration platform: one layer for all connections<\/h2>\n<p>A platform flips the architecture: systems no longer connect to each other pair by pair, they all connect to a single hub. The hub provides connectors to the individual systems, data transformations (different codes, units, item matching), queues with automatic retries on outages and, above all, oversight \u2014 transfers are monitored and you learn about an error from a notification, not from a customer. Adding another system means adding one connector, not rebuilding all existing connections.<\/p>\n<ul class=\"ep-cards\">\n<li><strong>Bridge<\/strong>One connection, a fixed scenario. A second flow or a third system = a new bridge, a new vendor, more management.<\/li>\n<li><strong>Platform<\/strong>Multiple systems and directions through one hub. A new system = one connector; existing connections stay untouched.<\/li>\n<li><strong>Bridge<\/strong>Errors typically get fixed once somebody notices \u2014 there is no log and no alerting.<\/li>\n<li><strong>Platform<\/strong>An outage is retried automatically from the queue, you know about errors immediately and the log lets you trace every transferred document.<\/li>\n<\/ul>\n<h2>When a bridge is enough<\/h2>\n<p>Honestly: quite often. Don\u2019t buy a platform if all three points hold:<\/p>\n<ol class=\"ep-steps\">\n<li><strong>Two systems, one or two flows.<\/strong> Orders one way, stock back \u2014 and nothing else on the horizon.<\/li>\n<li><strong>A standard scenario without customisation.<\/strong> The default mapping fits; no recalculations or matching needed along the way.<\/li>\n<li><strong>An outage can wait a while.<\/strong> If a transfer gets stuck, you\u2019ll notice yourselves and an hour\u2019s delay hurts nobody.<\/li>\n<\/ol>\n<h2>Five signals you need a platform<\/h2>\n<ol class=\"ep-steps\">\n<li><strong>Three or more systems.<\/strong> ERP + e-shop + warehouse, CRM or a carrier. The number of direct connections grows faster than linearly with each system \u2014 and so does the number of places where things can break.<\/li>\n<li><strong>Data needs transforming on the way.<\/strong> Unit conversions, matching product codes, splitting documents \u2014 a bridge\u2019s fixed mapping can\u2019t handle that.<\/li>\n<li><strong>Your operations depend on the transfers.<\/strong> When orders stop flowing, dispatch stops. Then you need monitoring, notifications and automatic retries, not a morning \u201cdid it go through?\u201d check.<\/li>\n<li><strong>A custom application or a system without a ready-made connector.<\/strong> Nobody sells a bridge for your in-house app; a platform connects over its API.<\/li>\n<li><strong>You need to prove what was transferred.<\/strong> Complaints, audits, hunting for differences between systems \u2014 without logs you argue, with logs you look it up.<\/li>\n<\/ol>\n<h2>What about Make, Zapier or n8n?<\/h2>\n<p>Those are integration platforms too \u2014 general-purpose ones. They are great for marketing automation and notifications; with accounting documents you will run into the fact that none of them knows Czech and Slovak ERP systems, their documents, editions and validations. We compared the general and the specialised approach <a href=\"\/en\/erpedie\/make-zapier-n8n-pohoda\/\">using POHODA as the example<\/a> \u2014 in short: fine for a prototype, not for the company\u2019s backbone.<\/p>\n<div class=\"ep-note\">\n<h2>A trap: \u201cplatform\u201d in an offer means nothing by itself<\/h2>\n<p>Everybody writes platform into their offers these days. Four questions cut through it: <strong>What exactly happens when a transfer fails?<\/strong> (the right answer includes a queue, retries and a notification) <strong>Where do I see the log of transferred documents?<\/strong> <strong>Who watches the operation \u2014 you or us?<\/strong> <strong>What will adding another system cost in a year?<\/strong> Whoever answers concretely actually has a platform.<\/p>\n<\/div>\n<h2>How we do it at Symmy<\/h2>\n<p>Symmy is a cloud integration platform built for Czech and Slovak ERP systems: it automatically monitors, transforms and validates data between systems, operations run under 24\/7 supervision and the build is priced per module (usually 6\u201312 hours of work per module), so you pay for the flows you actually need. Supported pairs are listed in the <a href=\"\/en\/enterprise-and-erp-systems-to-integrate\/\">integration catalogue<\/a>; how the whole discipline works is covered by the <a href=\"\/en\/erpedie\/integrace-erp-systemu\/\">complete ERP integration guide<\/a>.<\/p>\n<h2>Frequently asked questions<\/h2>\n<details class=\"ep-faq\">\n<summary>Is an \u201cintegration platform\u201d the same thing as iPaaS?<\/summary>\n<p>Yes, iPaaS (integration Platform as a Service) is the industry term for a cloud integration platform. In practice you distinguish general iPaaS (Make, Zapier, n8n) from specialised platforms that know a specific domain \u2014 in our case Czech and Slovak ERP systems and their documents.<\/p>\n<\/details>\n<details class=\"ep-faq\">\n<summary>How much does an integration platform cost?<\/summary>\n<p>You don\u2019t pay for \u201csoftware\u201d, you pay for the flows that get built and for operation. With us the build is priced per module (usually 6\u201312 hours per module) and operation is a monthly fee \u2014 the <a href=\"\/en\/enterprise-and-erp-systems-to-integrate\/\">online calculator<\/a> prices your specific pair of systems. A bridge is cheaper on day one; a platform wins on management and extensibility.<\/p>\n<\/details>\n<details class=\"ep-faq\">\n<summary>Do I have to change my ERP or e-shop for a platform?<\/summary>\n<p>No. A platform connects to the systems you already have through their interfaces \u2014 API, XML, database. That is exactly why it makes sense where no ready-made bridge exists for your combination.<\/p>\n<\/details>\n<details class=\"ep-faq\">\n<summary>What if one of the systems goes down?<\/summary>\n<p>No data is lost \u2014 it waits in the queue and the transfer retries automatically until the system is back. You learn about the outage from a notification, and the log then shows that everything went through.<\/p>\n<\/details>\n<details class=\"ep-faq\">\n<summary>Won\u2019t AI solve all of this?<\/summary>\n<p>No \u2014 an AI layer is great for questions over your data, but transferring documents needs a deterministic machine: same input, same output, every time. Why the two layers complement rather than compete is covered in <a href=\"\/en\/erpedie\/mcp-vs-klasicka-integrace\/\">MCP server or a classic integration<\/a>.<\/p>\n<\/details>\n","protected":false},"excerpt":{"rendered":"<p>A bridge connects two systems; an integration platform keeps all your connections in one place. What the term actually means, when a platform is overkill and the signals that tell you it&#8217;s time.<\/p>\n","protected":false},"author":0,"featured_media":67153,"template":"","class_list":["post-71972","erpedie","type-erpedie","status-publish","has-post-thumbnail","hentry"],"acf":[],"_links":{"self":[{"href":"https:\/\/symmy.com\/en\/wp-json\/wp\/v2\/erpedie\/71972","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/symmy.com\/en\/wp-json\/wp\/v2\/erpedie"}],"about":[{"href":"https:\/\/symmy.com\/en\/wp-json\/wp\/v2\/types\/erpedie"}],"version-history":[{"count":0,"href":"https:\/\/symmy.com\/en\/wp-json\/wp\/v2\/erpedie\/71972\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/symmy.com\/en\/wp-json\/wp\/v2\/media\/67153"}],"wp:attachment":[{"href":"https:\/\/symmy.com\/en\/wp-json\/wp\/v2\/media?parent=71972"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}