Technical project case study
A scheduled browser automation was designed to identify the first eligible wholesale order in Sellercloud and post it to Peoplevox within a controlled evening window, without creating duplicate warehouse orders.
01The operational problem
A wholesale order created late in the trading day still needed to reach the warehouse system in time for the next operational cycle. The existing task was small, but it depended on a person remembering to open Sellercloud, find the correct order and choose the Peoplevox posting action.
This is a common integration problem: the manual step is simple, yet the consequences of omission or duplication are disproportionate. A missed post delays fulfilment; a repeated post risks duplicate demand in the warehouse. The requirement was therefore not merely to automate a click, but to prove eligibility and make repeated execution safe.
02What was built
ECom Clarity built a Playwright-based worker that signs into the existing Sellercloud interface, searches for a recent unprocessed Wholesale order and invokes the established Post to Peoplevox action. It runs Sunday to Thursday in a defined Europe/London window, polling only for the limited period in which the business needs the hand-off.
The automation deliberately processes the first qualifying order rather than attempting an unrestricted batch. Processed Sellercloud order IDs are stored locally, allowing the worker to stop safely if a scheduled job restarts or is triggered twice.
03Technical design
- Playwright controls the authenticated Sellercloud web workflow where a stable application API was not the selected route.
- Eligibility is constrained by channel, creation time, processing state and the configured UK operating window.
- A persistent processed-order ledger supplies idempotency across runs.
- A headed inspection mode allows maintainers to examine the Sellercloud Actions menu without pressing the live posting action.
- A macOS LaunchAgent provides unattended scheduling while keeping credentials in environment configuration rather than source control.
04Controls, failure handling and operational safety
- The worker exits quietly when no eligible order exists.
- Previously processed order IDs are rejected before any posting action.
- Inspection and one-shot test modes separate diagnosis from live execution.
- The polling window is finite, preventing a stale process from acting later in the night.
- Selectors and navigation assumptions are isolated so changes to Sellercloud can be tested before the scheduled job is restored.
05Why the design matters
The project removes a routine dependency without pretending that browser automation is the same as a formal API integration. It uses the interface because that matched the available operational path, then adds the controls normally expected from an integration: eligibility rules, idempotency, time boundaries, logs and a diagnostic mode.
The useful outcome is consistency. The warehouse hand-off no longer relies solely on memory, while the business retains a comprehensible workflow that can be observed and stopped.
06What this project demonstrates
- Sellercloud and Peoplevox process knowledge, not just generic browser scripting.
- Proportionate automation for a narrow operational gap.
- Duplicate prevention and safe unattended scheduling.
- A maintainable path for systems that do not expose every required action through a suitable API.
07Practical lessons for similar integrations
Automate the business decision before the button press. The strongest control is the definition of an eligible order, not the speed of the script.
Browser automation should be observable and bounded. A live action needs a dry-run or inspection route, a record of completed work and an explicit response when the upstream interface changes.