Advertising
Hear about a rejected product the same day
A product gets rejected from the catalogue and nothing announces it. Sales for that item simply stop, and the cause surfaces a fortnight later when somebody finally opens the diagnostics tab. Both platforms already publish the rejection through an API. What is missing is not the data — it is a flow that reads it on a schedule and puts the affected item codes in front of the person who can fix the field.
- Triggers
- Two
- Runs
- Daily
- Stack
- 4 tools
- Durable execution
- Not required
The flow
The top track catches what fails at upload. The bottom track catches what fails afterwards, in processing — and only the second knows whether the listing is actually off.
Poll the upload sessions
n8n schedule
Pull that session's errors
Meta Marketing API
Log one row per item
Sheets · Airtable
Every morning
n8n 排程
Read product statuses
Google Merchant API
Anything actually blocked?
n8n IF
Send the item codes
Slack · WhatsApp
Log only
—
Step by step
- 01
Poll the upload sessions
n8n scheduleMeta pushes nothing when an upload finishes, so this side asks: list the sessions and find the one that just completed. Each session is addressable, so its errors can be read as a set rather than fished out of a dashboard.
- 02
Pull that session's errors
Meta Marketing APIRequest the error report for the session you just uploaded. Keep the fatal and the warning rows separate — treating a warning as a rejection trains people to ignore the alert.
- 03
Log one row per item
Sheets · AirtableItem code, the attribute at fault, the error text, and the date. The same code appearing week after week is the signal worth acting on, and only a log shows it.
- 04
Every morning
n8n 排程Runs well after the upload, because a clean upload is not the same as an approved product. The gap between the two is where this whole flow lives.
- 05
Read product statuses
Google Merchant APIPull the processed status for each item, including its issues and the destinations they affect. This is the reading that reflects the item as the platform now holds it, not as you sent it.
- 06
Anything actually blocked?
n8n IFFilter on whether the item is prevented from showing, not on whether it has an issue at all. Most catalogues carry standing warnings, and alerting on those is how an alert channel dies.
- 07
Send the item codes
Slack · WhatsAppName the items, the attribute at fault, and the destination affected. "Some products were rejected" sends the reader back into the dashboard, which is the work you were trying to remove.
What the platform will not allow
The reason this runs on a timer rather than firing the instant you upload is written into both platforms' documentation.
Google states plainly that a product is not judged the moment you send it: "There is a delay, typically a few minutes, between when a productInput is inserted or updated and when the changes are reflected in the final processed product." A check that fires on upload is checking the wrong copy of the item.
Merchant API — List your products data and product issuesThe processed record carries both destinationStatuses — "an array indicating the approval status of the product for each destination" — and itemLevelIssues, where "each issue includes a description, severity, the affected attribute, and documentation to help you resolve it". The affected attribute is the field that makes an alert actionable, and it is already in the response.
Merchant API — List your products data and product issuesNot every issue takes a product down. Google's servability field distinguishes "disapproved: The problem prevents the product from being shown" from "unaffected: The product is still shown", and a separate resolution field "informs if the merchant can solve the issue" at all. Alerting on both classes is how the channel gets muted.
Content API for Shopping — Product statusesOn Meta, a scheduled feed cannot be your fast path: "Scheduled feeds do not support uploads more frequently than once per hour." A correction pushed by re-uploading the feed is paced by that ceiling, whatever your workflow's own cadence is.
Meta Marketing API — Catalog Feed API referenceMeta publishes no webhook for a finished feed upload; the upload sessions are read by listing them, which is why the first node here is a schedule and not a platform push.
Marketing API — Product Feed UploadMeta exposes the upload's own failures as a retrievable document — "an error report about your data feed uploads, with warning errors and fatal errors highlighted" — which is what lets the top track read a whole session at once instead of scraping Commerce Manager.
Meta Marketing API — Product Feed Upload error report
When this is not worth building
Three cases where the upkeep costs more than the silent rejections.
The catalogue is small enough to eyeball. Thirty items and a weekly glance at the diagnostics tab beats a workflow, because you will notice the missing product before the alert does.
Nobody can change the source data. If the feed is generated by a system you do not control, the alert names a field that stays wrong, and the daily message becomes a record of powerlessness.
Your feed already carries standing warnings nobody has cleared. Build the alert on top of that and every run reports the same backlog, which teaches the channel to be ignored before it ever catches something new.