REST integration with a retail POS and Brazilian tax reform rollout

Challenge

A multi-brand apparel maker runs its own stores on top of a market-standard POS platform, while billing, stock and in-house credit live in the ERP. The two ends needed to talk across nine fronts: customer, product, price, stock, invoice, order, return, in-house credit and tax status. The complication sat in the POS API, which imposes a request limit. A full daily load blew past that limit well before finishing.

Midway through the project came the Brazilian tax reform. Invoices already issued needed to start carrying IBS and CBS, and the client had no way of waiting for the ERP’s next version cycle.

Solution

Instead of a full load, I implemented incremental synchronisation built on the ERP’s own native change log: the monitor reads what changed since the last processed point and publishes only the delta. That brought the call volume to the API down to a fraction of what it was and left the sync window close to continuous.

The request limit is still there even with lower volume, so I built a custom rate limiter, with a queue and progressive backoff on rejection, so that a sales spike would not bring the whole integration down. A failed item becomes an individual pending record and gets reprocessed later, without aborting the batch.

For the tax reform, I wrote the batch re-import and recalculation routine for IBS/CBS over invoices already issued, item by item, with a divergence report before writing. Along with it came a set of point fixes for the side effects that surfaced: swapped tax series, missing NF-e key and Sefaz response, an incorrect zeroing of ICMS in the “other” category.

Outcome

The store started seeing the ERP’s stock and price within minutes, rather than the next day, and the ERP started receiving sales, returns and in-house credit entries without manual typing. The tax backfill was completed within the legal deadline, over the already-issued base, without waiting for a standard product release.

What this case shows

I integrated with a third-party API that has a real rate constraint, and log-driven incremental synchronisation was the option that would fit inside that constraint. The tax side shows a quick response to a change in legislation, including retroactive correction of tax data that had already been persisted.