Every sync request signed, timestamped and impossible to replay
Connecting multiple WooCommerce stores usually means opening up REST API keys with broad permissions and hoping nobody intercepts a request in transit. A leaked key or a replayed request can mean stock levels, prices or order data being manipulated without anyone noticing until the damage is done.
Stillpoint signs every single request between the hub and each connected store with HMAC, stamped with the exact time it was sent and a nonce that can only ever be used once. Pairing a store issues a scoped key limited to sync operations, and that key can be revoked instantly from the hub — so a compromised store, a decommissioned site, or a departing agency contractor never leaves a lingering security hole.
Key benefits
HMAC-signed payloads
Every request body is signed with a shared secret established during pairing, so a tampered payload is rejected before it touches WooCommerce data.
Timestamp and nonce checks
Each request carries a timestamp and single-use nonce; requests outside the allowed window or reusing a nonce are refused, closing off replay attacks.
Scoped, revocable keys
Pairing keys are limited to sync functions only — not full WordPress admin access — and can be revoked per store without affecting the rest of your network.
No shared master password
There's no single admin credential shared across stores; each connection has its own key pair, so one breach doesn't cascade to every site.
Transport-level encryption
Requests travel over HTTPS with signing on top, so even a network-level observer can't read or usefully alter the sync traffic.
Full audit trail
Every signed request, accepted or rejected, is recorded in the activity log, so you can see exactly what was sent, when, and by which store.
How it works
- 1
Pair the store
During setup, the hub and the child store exchange a scoped secret key used only for signing sync requests.
- 2
Build the request
Before sending any sync payload, Stillpoint attaches a timestamp and a freshly generated nonce.
- 3
Sign the payload
The full request — data, timestamp and nonce — is hashed with HMAC using the store's secret key.
- 4
Verify on receipt
The receiving store recalculates the signature and checks the timestamp window and nonce history before accepting anything.
- 5
Accept or reject
Valid requests are processed and logged; anything failing signature, timing or nonce checks is dropped and flagged in the activity log.
Real-world examples
A footwear brand runs its UK hub alongside AU and DE storefronts. When the hub pushes a price update ahead of a seasonal sale, each payload is signed and timestamped before it leaves the UK server, so even though the request crosses three time zones and different hosting providers, the AU and DE stores can verify it came from the real hub and hasn't been altered en route.
During a routine security review, the retailer's IT contractor asks how a rogue actor couldn't simply capture a sync request and resend it later to force a stock rollback. The nonce system answers that directly: a captured request can never be replayed, because the one-time nonce is already marked as used the instant the original request is processed.
When the retailer ends its contract with an external agency that had managed the DE store, they revoke that store's pairing key from the hub dashboard in seconds — no need to change passwords across the whole network or worry that the agency retains any lingering access.
Who it's for
Built for multi-store merchants and agencies who need sync traffic between stores to be verifiably authentic and who can't accept shared, unscoped API credentials as a security model.
Frequently asked questions
Ready to put secure signed transport to work?
See pricing and pick the plan that matches how many stores you run.