{"id":28757,"date":"2025-11-16T08:44:00","date_gmt":"2025-11-16T07:44:00","guid":{"rendered":"https:\/\/www.web-systems.pl\/api-system-integration-store-crm-erp-warehouse\/"},"modified":"2025-11-16T08:44:00","modified_gmt":"2025-11-16T07:44:00","slug":"api-system-integration-store-crm-erp-warehouse","status":"publish","type":"post","link":"https:\/\/www.web-systems.pl\/en\/api-system-integration-store-crm-erp-warehouse\/","title":{"rendered":"API system integration &#8211; how to connect your store, CRM, ERP, payments and warehouse"},"content":{"rendered":"\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_86 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Spis tre\u015bci<\/p>\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.web-systems.pl\/en\/api-system-integration-store-crm-erp-warehouse\/#Why_API_system_integration_decides_how_smoothly_a_company_runs\" >Why API system integration decides how smoothly a company runs<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.web-systems.pl\/en\/api-system-integration-store-crm-erp-warehouse\/#The_data_flow_map_what_we_really_connect_between_the_store_CRM_ERP_and_warehouse\" >The data flow map: what we really connect between the store, CRM, ERP and warehouse<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.web-systems.pl\/en\/api-system-integration-store-crm-erp-warehouse\/#API_integration_patterns_REST_webhooks_queues_and_batch_synchronization\" >API integration patterns: REST, webhooks, queues and batch synchronization<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.web-systems.pl\/en\/api-system-integration-store-crm-erp-warehouse\/#Typical_mistakes_and_traps_that_cost_the_most_in_integration_projects\" >Typical mistakes and traps that cost the most in integration projects<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/www.web-systems.pl\/en\/api-system-integration-store-crm-erp-warehouse\/#Security_data_and_compliance_in_API_integrations\" >Security, data and compliance in API integrations<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/www.web-systems.pl\/en\/api-system-integration-store-crm-erp-warehouse\/#Scalability_monitoring_and_maintaining_the_integration_after_go-live\" >Scalability, monitoring and maintaining the integration after go-live<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/www.web-systems.pl\/en\/api-system-integration-store-crm-erp-warehouse\/#FAQ_%E2%80%93_the_most_common_questions_about_integrating_a_store_CRM_ERP_and_payments\" >FAQ &#8211; the most common questions about integrating a store, CRM, ERP and payments<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/www.web-systems.pl\/en\/api-system-integration-store-crm-erp-warehouse\/#How_long_does_an_API_integration_between_a_store_and_an_ERP_take\" >How long does an API integration between a store and an ERP take?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/www.web-systems.pl\/en\/api-system-integration-store-crm-erp-warehouse\/#Is_a_ready-made_plugin_better_or_a_custom_API_integration\" >Is a ready-made plugin better, or a custom API integration?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/www.web-systems.pl\/en\/api-system-integration-store-crm-erp-warehouse\/#What_happens_when_one_of_the_systems_stops_responding\" >What happens when one of the systems stops responding?<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/www.web-systems.pl\/en\/api-system-integration-store-crm-erp-warehouse\/#Summary_and_contact_%E2%80%93_integration_as_an_investment_in_company_consistency\" >Summary and contact &#8211; integration as an investment in company consistency<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Why_API_system_integration_decides_how_smoothly_a_company_runs\"><\/span>Why API system integration decides how smoothly a company runs<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Almost every growing e-commerce business sooner or later hits the same wall: the data sits in separate systems, and those systems do not talk to each other. The store knows about orders, the CRM about customers, the ERP about invoices, the warehouse watches stock levels &#8211; and each of these worlds does its own thing, its own way. <strong>API system integration<\/strong> is the layer that ties these islands into a single flow of information. Instead of making people copy data by hand from one application into another.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">And this is not an abstract problem. It is a real cost. An employee who retypes an order from the store into the ERP loses time, and sooner or later will get it wrong &#8211; it is only a matter of when. Stock levels refreshed once a day? Fine, then you sell something that is no longer physically on the shelf. Delays in the flow of information hit customer service, and inconsistent data can wreck any report.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The symptoms of missing integration are fairly distinctive. They include, among others:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>recurring complaints caused by incorrect stock levels,<\/li>\n<li>orders that &#8220;get lost&#8221; somewhere between the store and the fulfillment team,<\/li>\n<li>several versions of the same customer record across different systems,<\/li>\n<li>sales reports that never add up.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">At Web Systems we treat integration as an architectural project, not a one-off script gluing two systems together at the seam. A script solves the problem for today. But the first time the vendor changes its API it stops working, and nobody remembers why anymore. A well-designed integration assumes from the start that something will change, clearly defines what each system is responsible for, and describes what happens when something goes wrong. Since 2006 we have been <a href=\"https:\/\/www.web-systems.pl\/en\/software-development\/\">building custom software<\/a>, and we know one thing: the difference between a stopgap and a considered architecture only shows up in the third month, when order volume starts to grow.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"The_data_flow_map_what_we_really_connect_between_the_store_CRM_ERP_and_warehouse\"><\/span>The data flow map: what we really connect between the store, CRM, ERP and warehouse<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Before we write the first line of code, we draw a data flow map. Without it, integration turns into a tangle of connections that nobody can later unravel. A typical flow in a retail company looks fairly predictable &#8211; except that the devil, as always, is in the details of each step.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The standard order path runs as follows:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>the customer places an order in the store,<\/li>\n<li>the payment gateway confirms the payment,<\/li>\n<li>a sales document and an invoice are created in the ERP,<\/li>\n<li>the warehouse reserves specific stock for fulfillment,<\/li>\n<li>the contact and the customer&#8217;s purchase history are updated in the CRM.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">And at every one of these stages the same question comes back: which system is the <strong>source of truth<\/strong> for a given type of data. This concept, known in application architecture as the single source of truth, means that for each kind of information there is exactly one owner entitled to change it. The product price can come from the ERP, the description and photos from the store, the stock level from the WMS, and the customer&#8217;s contact details from the CRM.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Trouble starts where two systems both want to rule the same record. If both the store and the ERP can change a price, sooner or later they will enter two different values, and synchronization will start overwriting them in random order. And there you have a ready recipe for duplicate records, stock conflicts and the classic situation where nobody knows which number is the real one.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">That is why the first design decision is to establish unambiguously who is in charge. We name the master system for prices, for stock levels and for personal data, and treat the rest as consumers of that information. This discipline eliminates most conflicts before they even appear. The flow map also becomes documentation you come back to with every subsequent change &#8211; for example when the company adds a second sales channel or a new payment system.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"API_integration_patterns_REST_webhooks_queues_and_batch_synchronization\"><\/span>API integration patterns: REST, webhooks, queues and batch synchronization<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">There is no single universal way to connect systems. The choice of pattern depends on volume, on the delays you are able to swallow, and on what the vendor&#8217;s API actually offers. Most often we reach for REST with polling, event-driven webhooks, message queues and batch synchronization &#8211; and we mix them depending on the specific flow.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">REST with polling is nothing more than periodically asking a system &#8220;are there any new orders&#8221;. Simple, predictable, but with frequent polling it loads the API and adds delay. Webhooks work the other way round: the source system tells us about an event the moment it happens. The reaction is almost instant, you just need a reliable receiver and a plan for the situation where the notification simply does not arrive.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">With high order volume it is worth introducing a message queue and an event broker. The queue works as a buffer &#8211; it accepts events faster than the target systems can process them and then releases them at a controlled pace. As a result, a sales peak does not clog the ERP, and no order evaporates during a momentary overload.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Another important decision: point-to-point integration or an intermediate layer? Connecting &#8220;everything to everything&#8221; works with two or three applications. But with five it turns into a spider web that cannot be maintained. Middleware, that is, a dedicated integration layer, centralizes the data exchange logic and cuts the cost of later changes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">We match the synchronization mode to the nature of the data. Stock levels and payment statuses require something close to real time. Reports or catalog updates, on the other hand, will happily tolerate a batch mode run every few hours.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Tip:<\/strong> when choosing a pattern, run through four criteria &#8211; transaction volume, acceptable latency, how critical the data is, and what the vendor&#8217;s API can realistically do. That last point is the one most often swept under the rug, and it is exactly the one that decides whether webhooks are an option at all.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Typical_mistakes_and_traps_that_cost_the_most_in_integration_projects\"><\/span>Typical mistakes and traps that cost the most in integration projects<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The most expensive mistakes in integrations do not come from exotic technologies. They come from skipping a few fundamental principles. We see them regularly when we take over projects someone else previously delivered &#8220;in a hurry&#8221;. Most problems boil down to one thing: no resilience against unusual situations.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The first sin is the lack of idempotency. Idempotency means that the same operation performed twice produces the same result as performing it once. Without it, retrying an order after a failed connection creates a second, duplicate document, and in the extreme case charges the payment twice. The cure? Giving every operation a unique key that the target system recognizes and simply rejects on a repeat.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The second trap is ignoring the limits and timeouts of external APIs. Every payment gateway and every ERP imposes a rate limit, that is, a maximum number of requests per unit of time. An integration that does not know about it will get blocked at the worst possible moment &#8211; in the middle of a sale. Likewise, an unhandled timeout can freeze an entire flow, waiting endlessly for a response that will never come.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The third mistake: no retry queue. Systems are sometimes temporarily unavailable. The ERP goes through an update, the gateway has scheduled maintenance &#8211; business as usual. An integration without a retry mechanism simply loses such events. A mature solution records the failed operation, retries it with a growing interval, and once the attempts are exhausted moves it to a queue requiring manual intervention.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The fourth trap is architectural in nature: hard coupling to a specific vendor. If the integration code is written tightly around one payment gateway, switching providers means rewriting half the system. It is smarter to go for abstraction &#8211; a common interface behind which we hide the details of the specific vendor. Then swapping a component is a targeted change, not a costly project from scratch.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Security_data_and_compliance_in_API_integrations\"><\/span>Security, data and compliance in API integrations<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">An integration pushes sensitive data across the network: orders, invoices, customers&#8217; personal data, payment information. Security is not an add-on here, nor an option for later. It is a boundary condition. From experience I know that bolting on protections after the rollout costs many times more than designing them in from the start.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The basics are authentication and authorization. Simple API keys work in simple cases, but for connections handling personal data we recommend OAuth2 with short-lived tokens. Secret rotation matters just as much &#8211; regularly replacing keys and tokens so that a potential leak has a limited window of opportunity. A static key that has not changed for years is a risk quietly building up in the background.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The entire transmission has to be encrypted, and the scope of transferred data trimmed to the necessary minimum. If the warehouse only needs the order identifier and the product list, why should the customer&#8217;s full payment card details end up there? The data minimization principle reduces the attack surface and simplifies regulatory compliance.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Personal data in the CRM and ERP is subject to GDPR. That means an obligation to log access, to control who read specific information and when, and to be able to delete it on request. An integration should respect these requirements, not work around them for convenience. A well-designed flow lets you point to the route a piece of personal data took and where it came to rest.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Tip:<\/strong> never keep secrets in the code or in the repository. Never. Keys and passwords should live in a dedicated secret store (a vault) or in environment variables, away from the application logic. It is also worth versioning API contracts, that is, the formal descriptions of what data the systems exchange and in what structure. Versioning ensures that a change on one system&#8217;s side does not quietly break the integration with the rest.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Scalability_monitoring_and_maintaining_the_integration_after_go-live\"><\/span>Scalability, monitoring and maintaining the integration after go-live<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Go-live is not the end. It is only the beginning of the integration&#8217;s life. Many clients assume that once systems are connected they will keep running unattended forever &#8211; yet an integration is a living organism. Vendors change their APIs, publish new versions, retire old endpoints. And every such change can quietly break the data flow.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">That is why we design monitoring from the very beginning. Without it, the first news of a failure is often a phone call from an angry customer whose order was never fulfilled. Sensible monitoring covers at least:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>alerts about failed synchronizations sent to the team in real time,<\/li>\n<li>a dashboard showing the number of processed and rejected events,<\/li>\n<li>latency metrics between placing an order and its appearance in the ERP,<\/li>\n<li>a check on the growing retry queue, which signals a building problem.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">End-to-end order tracing matters just as much. When something goes wrong, we have to be able to follow a single transaction from the click in the store, through payment and the ERP, all the way to the warehouse reservation. Consistent logs with a correlation identifier cut diagnosis from hours to minutes. Without them, hunting for the cause is like leafing through several separate journals with no common point of reference.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Scaling for seasonal peaks is a separate matter. Black Friday or the pre-holiday period can multiply traffic within a few hours. An architecture based on queues and well-considered buffering will absorb such a peak without losing stock consistency. A point-to-point integration? That one simply clogs up. At Web Systems we plan capacity with a margin, because adding it in the middle of a sales peak is the worst possible moment for changes. And maintenance is also a budget item worth planning for up front.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"FAQ_%E2%80%93_the_most_common_questions_about_integrating_a_store_CRM_ERP_and_payments\"><\/span>FAQ &#8211; the most common questions about integrating a store, CRM, ERP and payments<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Below we have collected the questions we hear most often from clients while discussing integration. The answers are based on real projects, not on generalities.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"How_long_does_an_API_integration_between_a_store_and_an_ERP_take\"><\/span>How long does an API integration between a store and an ERP take?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">That depends above all on the maturity of both systems&#8217; APIs and on the number of flows to connect. A simple integration of orders and stock levels with a well-documented API usually wraps up within a few weeks. More elaborate projects &#8211; invoices, corrections, multiple sales channels, unusual business rules &#8211; take longer. And interestingly, the biggest chunk of time goes not into the coding itself but into agreeing on the sources of truth and handling the edge cases nobody had described before.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Is_a_ready-made_plugin_better_or_a_custom_API_integration\"><\/span>Is a ready-made plugin better, or a custom API integration?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A ready-made plugin can be a good choice to start with, when the processes are standard and fit within its assumptions. The problem crops up with unusual rules: custom stock reservation logic, multiple warehouses, a specific invoice workflow. Then a custom integration, despite the higher entry cost, turns out to be cheaper to maintain &#8211; because it does not force the company to bend itself around the tool&#8217;s limitations. We often recommend a middle path &#8211; a custom layer on top of proven components.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"What_happens_when_one_of_the_systems_stops_responding\"><\/span>What happens when one of the systems stops responding?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In a well-designed integration nothing is lost. Events go into a queue, are retried with a growing interval, and once the system is back they are processed in order. The customer does not even see the outage, and the team gets an alert and can react before the problem grows.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Summary_and_contact_%E2%80%93_integration_as_an_investment_in_company_consistency\"><\/span>Summary and contact &#8211; integration as an investment in company consistency<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A well-designed <strong>API system integration<\/strong> is not a cost but an investment that pays off in orderly data. It cuts the errors of manual retyping, speeds up order handling and finally makes the reports add up. Instead of several islands with their own version of the truth, the company gets one coherent flow of information in which every system has a clearly assigned role.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">From our experience there are four decisions worth making consciously right at the start:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Source of truth<\/strong> &#8211; unambiguously naming the master system for prices, stock levels and customer data.<\/li>\n<li><strong>Data exchange pattern<\/strong> &#8211; choosing REST, webhooks, queues or batch synchronization to match the real volume and requirements.<\/li>\n<li><strong>Security<\/strong> &#8211; authentication, encryption, data minimization and GDPR compliance.<\/li>\n<li><strong>Maintenance<\/strong> &#8211; monitoring, alerts and resilience to vendor API changes and seasonal peaks.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Each of these elements can be designed well or put off until later and paid for many times over during operation. And that difference shows after a few months of the system running, when order counts grow and situations appear that a makeshift script never anticipated.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Web Systems is a software house from \u0141\u00f3d\u017a that since 2006 has been designing and delivering web and mobile applications, B2B systems, API integrations, automations, e-commerce and <a href=\"https:\/\/www.web-systems.pl\/en\/development-of-artificial-intelligence-based-applications\/\">solutions based on artificial intelligence (AI)<\/a>. If you are planning to connect your store, CRM, ERP, payments and warehouse, building an MVP of a new application or thinking about automating or modernizing an existing system, <strong>get in touch with us<\/strong> &#8211; we will suggest where to start and how to do it so that it also works at a larger scale.<\/p>\n\n","protected":false},"excerpt":{"rendered":"<p>Why API system integration decides how smoothly a company runs Almost every growing e-commerce business sooner or later hits the same wall: the data sits in separate systems, and those systems do not talk to each other. The store knows about orders, the CRM about customers, the ERP about invoices, the warehouse watches stock levels [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[202,116,406],"tags":[149,300,595,134,709,500,774,283],"class_list":["post-28757","post","type-post","status-publish","format-standard","hentry","category-e-commerce","category-it","category-programowanie","tag-api","tag-automatyzacja","tag-crm","tag-e-commerce","tag-erp","tag-integracja-systemow","tag-magazyn","tag-wordpress"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/posts\/28757","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/comments?post=28757"}],"version-history":[{"count":0,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/posts\/28757\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/media?parent=28757"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/categories?post=28757"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/tags?post=28757"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}