Skip to content
pulsify
Pulsify
04 / How it runs Menu +

04 / How it runs

How it runs

Your agent writes and tests an automation. Pulsify runs it when Amazon reports something, long after the conversation ends, and records what happened at each step.

2 kinds of input

Events trigger runs. Selling Partner API notifications reach Pulsify through Amazon EventBridge and SQS. Amazon Marketing Stream messages arrive through SNS and SQS, with 1 queue for each advertising region: North America, Europe and Far East.

Refreshes keep readings current. Scheduled crawls and reports update what Pulsify knows about your listings, stock, sales and ads. A refresh never runs an automation. See refreshes below.

Subscriptions

These event types are always on for every connected seller: LISTINGS_ITEM_STATUS_CHANGE, LISTINGS_ITEM_ISSUES_CHANGE, LISTINGS_ITEM_MFN_QUANTITY_CHANGE, ORDER_CHANGE, FBA_INVENTORY_AVAILABILITY_CHANGES, ACCOUNT_STATUS_CHANGED, FEED_PROCESSING_FINISHED, FBA_OUTBOUND_SHIPMENT_STATUS, FULFILLMENT_ORDER_STATUS, ITEM_SALES_EVENT_CHANGE, DETAIL_PAGE_TRAFFIC_EVENT, BRANDED_ITEM_CONTENT_CHANGE. Pulsify also follows DATA_KIOSK_QUERY_PROCESSING_FINISHED and REPORT_PROCESSING_FINISHED to download reports; automations never run on those.

The rest subscribe when you activate an automation for them and unsubscribe when none needs them. Marketing Stream subscriptions also wait for Amazon to confirm. Hourly traffic and conversions stay subscribed while any advertising automation is active, because every campaign context reads them.

list_streams shows each subscription as active, inactive or pending, with a reason when it isn't active: no_active_automation, awaiting_confirmation or subscribe_failed.

A run, step by step

  1. Pulsify stores the event before acknowledging it. Amazon's own event id stops a redelivery from being stored twice.
  2. It creates 1 delivery for each target: every matching listing, or the seller for account-wide events, or the advertiser for Marketing Stream events. A notification Pulsify can't read stays on record and runs nothing.
  3. An event older than one already processed for the same target and type is stale. It changes nothing and runs nothing.
  4. The active automation for that event type on that account runs with event and context. There is at most 1.
  5. Pulsify drains context.mutations. Listing patches become requests on the listing's ledger. Advertising changes become automation actions.
  6. Requests go to Amazon after the run commits, and Amazon's answer is recorded separately. If a step fails, the delivery stays pending and retries. A completed delivery never runs twice.

4 facts, recorded separately

  1. Received. The event is stored.
  2. Processed. Its delivery to each target completed, including any automation run.
  3. Accepted. Amazon took the request: accepted on a listing request, applied on an advertising action.
  4. Observed. Amazon's next reading shows the new value.

An accepted request is not proof that Amazon shows the new value. Wait for the next reading. Amazon can report the old price for a while after accepting a new one, which is why the pricing templates wait up to 40 seconds before reacting to it.

Fresh data never rewrites your rules

Crawls, reports and events update Amazon's readings: price, stock, price bounds, listing status, the Buy Box. They never change your automation code, the thresholds in it, a listing block or a campaign switch. A submitted patch doesn't change a reading either. Only Amazon's next report does.

What each connection gives you

An account holds up to 1 selling connection and 1 advertising connection. connection_status shows both, and whether each is active.

Connection Readings Events and changes
Seller Central Listings, offers, stock, orders, daily sales, traffic and fees Selling events. Listing patches.
Amazon Ads Profiles per country and currency, campaigns, ad groups, ads, keywords and targets, daily advertising metrics Marketing Stream events. Campaign, ad group, ad and keyword changes.
Vendor Central Vendor analytics, through query_data None. A vendor account has no listings, and its only event type is handled internally.

Hourly sales and detail page traffic events, and search query performance, need Brand Analytics access on the selling account.

Refreshes

Source When What it updates
Listings crawl Every 6 hours Listings, status, price bounds, attributes, merchant stock
FBA inventory report Hourly listing.fba.inventory
FBA planning report Daily listing.fba.planning
Sales, traffic and fees Daily Daily sales and economics, get_sales_summary
Vendor analytics Daily, about 2 days behind Vendor metrics in query_data
Ads entities Daily, and when Amazon accepts an automation's change Campaigns, ad groups, ads, keywords and targets
Ads reports Daily Daily advertising metrics, get_ads_summary
Orders When you connect, then as ORDER_CHANGE events arrive Order history up to 10 years back, then each new order and status change

Each reading keeps its source's keys and units under listing.data. A missing source is not zero stock: check which source your automation reads. For how long each record is kept, see retention.

Next: what Pulsify checks around each run, and how to stop one, in Staying in control. The exact handler contract is in the reference.