iHerb + PochtaGlobal - Business Process Automation

Overview

The iHerb → PochtaGlobal route is a standard goods-reselling pipeline: the order is placed at a US store, lands at a mail-forwarder’s warehouse in the States, and the forwarder ships the parcel on to Russia. iHerb is one of the largest health-products retailers - 30,000+ items from 1,200 brands. PochtaGlobal is a delivery service moving parcels from the US, Europe and the UAE into Russia.

The client was an entrepreneur and his team reselling US health and beauty products in Russia. Between those two systems sat a person moving data by hand all day. A Browser Automation Studio bot took over that entire stretch: it collects order data from iHerb, creates purchases and parcels on PochtaGlobal, follows PGB tracking numbers, and pushes everything into a Telegram log channel and the business’s own accounting API.

System demo on YouTube

Problem

The work broke down into four monotonous stages, and all four scaled linearly with turnover.

First, filling in purchases: a large number of items had to be registered in the forwarder’s account so the US warehouse would know what was arriving and from whom. Then packing those purchases into parcels. In parallel, someone had to watch for new iHerb orders, pull the tracking numbers out of them, and fill in a PochtaGlobal form for each one. And finally, follow the status of dispatched PGB-XXX parcels, because customers ask where their order is.

The cost of a mistake here is concrete: a typo in a tracking number or a recipient’s name means a parcel the warehouse cannot match to a buyer. And the volume is high enough that an operator’s attention at 6pm is not what it was at 9am.

Solution

The bot runs as two independent loops on different schedules, both configurable in the UI: order refresh every 3,600 seconds and PGB track refresh every 86,400 seconds. Logins, passwords, the API key and the Telegram bot details are entered once in the resources dialog at launch and never live inside the script.

The key architectural decision: the browser is only needed to sign in. The bot authenticates in the iHerb account once and stores the cookies; on PochtaGlobal it stores the auth token. Everything downstream then runs as plain HTTP requests with no Chromium at all. That changes the scale of the thing - creating purchases and parcels for any number of tracking numbers takes seconds instead of minutes of DOM clicking, and nothing breaks when the site’s markup is redesigned.

The request body is assembled from the order data - the internal iHerb order ID, the recipient’s full name, the origin warehouse ("warehouse": "USA") - and passes a length check: the purchase name is truncated to the field’s 50-character limit, because iHerb product titles do not fit. That is the kind of detail you find on real data rather than at the design stage.

Every step’s result goes to two places: a Telegram log channel, as messages like “Order 925152933 updated. Track PGB-22212159 assigned / Postal track: CX400005202UZ” - and the business server’s API as JSON authenticated by API key, from where it flows into the accounting system.

Features

• Scheduled collection of order data from iHerb pages and monitoring of tracking numbers
• Session persistence: cookies for the iHerb account, an auth token for PochtaGlobal - no re-login each cycle
• Purchase and parcel creation on PochtaGlobal over HTTP requests, browserless - any number of tracking numbers per pass
• JSON payload assembly from order data, including origin warehouse and a 50-character cap on the name field
• Status tracking for dispatched PGB-XXX parcels and for the postal track (CX...UZ) appearing later, on its own slower interval
• Telegram log channel tagged #новыйтрек: order number, assigned PGB track, and the postal track or None when it has not been issued yet
• JSON feed to the business server’s API by API key - orders, tracks and statuses reach the accounting system without manual re-entry
• Configurable intervals for both loops: orders (3,600s by default) and PGB tracks (86,400s by default)
• Credentials and keys supplied through the launch-time resources dialog - see resources and input data in BAS

Development Process

The first version did everything through the browser - the easiest way to start, and the easiest way to hit a ceiling: across dozens of tracking numbers a run drags on, and any markup change on the service’s side breaks the scenario. So the logic moved onto the BAS HTTP client, and the browser was left with exactly one job - obtaining a session. After that the cookies and token live independently of the browser, and the rest of the pipeline is not tied to it.

Splitting the work into two loops with different periods also came from practice rather than planning. New orders appear often, and an hour is a sensible step. A parcel’s in-transit status changes slowly: checking more than once a day generates load and log noise without new information.

The Postal track: None lines in the log deserve a note of their own. That is not an unfinished feature but an honest state: the postal track is issued later than the PGB track, and the log shows exactly what is known at check time instead of hiding an empty field. The order comes back around on the next cycle and fills it in once it exists - the same scheduled re-check pattern that most jobs of this kind need.

Results

• A stretch of work that occupied a person all day now runs itself, from a new iHerb order to a created PGB parcel and a record in the accounting system
• Any number of tracking numbers is processed in a single HTTP pass instead of one form submission at a time
• Typos in tracking numbers and recipient names disappeared as a category - data is copied programmatically, not by eye
• The owner follows order movement from Telegram on a phone, without logging into two separate accounts
• The accounting system receives data through the API in real time, so stock and sales no longer need manual reconciliation
• Growing order volume and a wider catalogue require no rework: the load grows, the logic does not

What Was Learned

The main takeaway here is that a browser is worth keeping only where nothing else will do. Authentication genuinely needs a live session; form submission does not. Once the cookies and token are stored, everything else becomes an ordinary HTTP client: faster, immune to markup changes, and far easier to debug. That same move later carried into much larger automation systems, all the way to the RPA Automation Panel.

The second takeaway is about integration. Automation that works but delivers its output nowhere leaves the human exactly where they were - still opening the account and retyping numbers. The value appeared the moment the bot started writing to Telegram and to the accounting API: when its work became visible, and landed in the same data the decisions are made from.