Rulewave
Warehouse Management System for a global logistics service provider
System ArchitectureCloud SolutionsSystem IntegrationAutomation Solutions
An ERP, a warehouse system, a carrier, a payment provider and an accounting system are rarely designed to work together. We build the connections between them, move data in both directions, handle failures, and adapt the integration when either side changes.
Our partners
Orders, shipments, stock and documents remain consistent on both sides. The warehouse and back office no longer have to decide which system is correct. Rulewave, since 2019.
DHL integration from label creation to tracking, with no re-entering of data. Scanners display the same information as the central system, and suppliers book their own deliveries instead of calling the warehouse. Rulewave.
Stripe for subscriptions, e-invoices sent directly to Poland's KSeF system, and invoicing through external providers in the Netherlands and the US. Tesoro, TransHans and Rulewave.
Twilio, Gmail and Outlook. Calls and messages are assigned to the right customer, so the full conversation is available in one place. Tesoro.
Each vehicle's location is visible in the same system that handles ticket sales. TransHans.
Listings are published to Idealista, Fotocasa, Resales Online, A Place in the Sun and more than a dozen other portals. Each requires a different format, from XML to APIs. OpenAI translates listings and scores incoming leads. Tesoro.
Most integrations can work in either of two ways: data moves as changes happen or in a daily batch. The important difference is operational rather than technical, and it becomes clearest when something goes wrong.
| Real-time updates | Nightly batch | |
|---|---|---|
| When the two sides agree | As soon as anything changes | In the morning, after the overnight import |
| When something goes wrong | You see it immediately | You see it the next day, if somebody checks |
| Stock counts | No discrepancies to reconcile | Discrepancies that may be impossible to trace a week later |
| What people do | One state, one place to look | Somebody checks two systems and decides which to believe |
| Cost to build | Higher, because failures and retries have to be handled | Lower, because it is one export and one import |
| When it is enough | Warehouse operations, sales, payments, and other systems used throughout the day | Reports, accounting, archives |
In all three projects, the screens were not the hardest part. A global operator's warehouse, a CRM for estate agencies and a coach operator's ticketing system all depend on data reaching the right place at the right time.
Warehouse Management System for a global logistics service provider
CRM system for real estate agencies
A bus carrier's own ticket booking app
An integration rarely starts in ideal conditions. The other side is often a legacy system whose documentation stopped matching reality years ago.
Documentation is often out of date, so we inspect the API traffic and the data itself. A description written three years ago is a useful guide, not a source of truth.
Initial work takes place in a test environment using copied data. A mistake at that stage costs an hour, not a day of warehouse operations.
The new route runs alongside the old one until the figures match on both sides. Only then do we switch the old route off.
This is easy to overlook when choosing a supplier, but it is one of the main reasons our clients stay with us for years.
Integrations can fail quietly. No error reaches the user; the figures simply begin to drift apart.
Whether it is SAP, a carrier or a payment provider, we treat a change on their side as part of ongoing support rather than a separate project to quote.
Poland's KSeF e-invoicing rules evolve, and TransHans has used the system since 2022. We handle regulatory updates in the same way as API changes.
The same engineers who built the integration. Our staff turnover is low, which matters especially when maintaining complex connections between systems.
Usually, although the solution may not be what you expect. There may be a file export to a server, a readable database, a webhook, or an older protocol that the vendor no longer actively supports. We start with what the system can actually provide, not what its sales material promises. If there is no viable route, we say so immediately rather than relying on wishful thinking halfway through the project.
Sometimes we have, and sometimes we have not. We currently support SAP, DHL, Stripe, Twilio, KSeF and several MLS portals in production. With an unfamiliar system, we begin by studying its documentation and speaking to someone who knows it well. The key skill is understanding another provider's protocol, not having seen every product before.
This is one of the most common integration failures, and it rarely looks dramatic. Nothing crashes; a stock level or balance simply drifts away from reality. At the outset, we define which system is the source of truth for each type of record and provide a way to resend anything that did not get through. Without that, the first discrepancy usually ends with someone correcting data manually in a spreadsheet.
The system on the other side has the greatest influence on the timeline. A well-documented API with a test environment is very different from a system where gaining access takes three weeks of discussions with the vendor. Before quoting, we ask for the documentation and access to someone who knows the system. Only then can we give you a reliable date.
No. It affects the design but does not prevent the integration. Everything runs in the required region, using accounts that belong to your company. Because we are based in Poland, EU hosting and GDPR compliance are standard considerations for us. Where a record cannot be moved at all, we synchronise a reference rather than a copy.
Tell us which systems are involved and where their data begins to differ. We will respond with questions about the data, not a generic implementation proposal.