Storefronts and marketplaces
Catch a fee change before it eats the margin
A marketplace changes a commission band or a payment charge, publishes it, and the seller finds out from a settlement report weeks later. Nothing here is difficult: read the published schedule on a timer, keep yesterday's copy, and compare. The value is not the reading — it is that the comparison reaches the person who sets price on the day it moves, rather than after the next payout.
- Triggers
- Two
- Runs
- Daily
- Stack
- 4 tools
- Durable execution
- Not required
The flow
The top track captures. The bottom track judges. Two triggers, because a fee change reaches a seller two ways: on the published page, and in a notice nobody opens.
Every morning
n8n 排程
Pull the fee schedule
n8n · Make
Store today's copy
Sheets · Airtable
A seller notice arrives
n8n · Make
Compare with the last copy
n8n
Any rate changed?
n8n IF
Tell whoever sets price
Slack · WhatsApp
Leave the file as is
—
Step by step
- 01
Every morning
n8n 排程Once a day is enough. A fee schedule is not a price feed, and polling it harder buys nothing.
- 02
Pull the fee schedule
n8n · MakeFetch the published page and reduce it to the figures you actually price against — commission by category, payment charge, any campaign levy. Keep the raw copy too, so a wording change is visible later.
- 03
Store today's copy
Sheets · AirtableOne row per read, dated. Over a year this becomes the record of what the platform charged you and when it changed, which no seller centre will give you.
- 04
A seller notice arrives
n8n · MakeThe second way a change surfaces. Route the platform's announcement mail into the same flow so it is compared rather than filed.
- 05
Compare with the last copy
n8nField by field against the previous row. Compare the numbers, not the page — a redesign should not read as a fee change.
- 06
Any rate changed?
n8n IFSet a floor that matters to you. A rate that moves at the second decimal on a low-volume category is noise; the same move on your best seller is not.
- 07
Tell whoever sets price
Slack · WhatsAppName the old rate, the new rate, the effective date, and the SKUs it touches. A message that says only "fees changed" sends someone back to the seller centre, which is the work you were removing.
What the platform will not allow
Detecting the change is the easy half. Both acting on it and telling someone about it run into documented ceilings.
A WhatsApp customer service window opens when the user messages or calls you and resets if they do so again before it expires; once it closes "you can only send pre-approved template messages". A fee alert fired at 08:00 to a phone that has been quiet all week must therefore be a template, not free text.
WhatsApp Cloud API — Send messagesRepricing after a fee change is metered by calculated query cost, not request count: 100 points per second on standard Shopify plans, and no single query may exceed 1,000 points. A catalogue-wide reprice is paced by that budget, not by how fast your workflow can loop.
Shopify — API rate limitsproductVariantsBulkUpdate "updates multiple product variants for a single product in one operation" — the batch is one product, not one catalogue. A reprice across hundreds of products is hundreds of calls, and that is what sets how long the follow-up takes.
Shopify Admin GraphQL API — productVariantsBulkUpdate
When this is not worth building
Three cases where the upkeep costs more than the surprise.
You sell on one platform, in one category, at one rate. That is a single number to remember, and a workflow that watches one number is harder to maintain than the number is to check.
Your prices are set by contract or by a parent brand. Knowing a fee moved changes nothing if you cannot move price in response, and the alert becomes a monthly reminder that you are stuck.
The platform publishes fees only behind a seller-centre login that changes layout often. The flow will break quietly and keep reporting no change, which is worse than not having it — silence then reads as good news.