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 validates context.mutations. Listing and advertising requests enter the same immutable ledger, with automation decisions recorded separately.
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.

Requests for 1 target run in order. A submitting or uncertain request stops later requests from overtaking it. Known retryable rejections retry the same payload. Partial results, transport ambiguity and interrupted attempts stay uncertain instead of being blindly resent. Recovery restores lost queued jobs without rerunning a completed event delivery.

A creation targets its parent, and the new entity arrives later on that parent's receipt, never as a return value. An uncertain creation doesn't hold back the parent's other requests. Amazon offers no safe way to repeat a creation, so Pulsify asks Amazon what exists and settles the receipt as accepted, absent or unresolved. See creating entities.

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, as recorded by accepted and the provider outcome on its mutation receipt. An applied decision means validation and admission only.
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. An identity-matched, current entity returned by Amazon can update Ads observations; otherwise a later event or refresh supplies them.

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.

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

Refreshes

Each listing or Ads entity keeps native keys and units under 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.