Skip to content
pulsify
Pulsify
05 / Staying in control Menu +

05 / Staying in control

Staying in control

Pulsify enforces the mechanics around your automation. The automation holds the business rules, and you can stop it at any point.

Who owns what

  • Pulsify checks who may change what, validates input, processes deliveries, limits execution, controls submission and keeps the audit trail.
  • You own the business policy: pricing, thresholds and advertising strategy. That includes what an automation does with a price Amazon hasn't updated yet, or with a request it already made.

Pulsify runs your saved JavaScript as written. No model on Pulsify's side decides business actions.

Before it runs

Saving checks the syntax, that the code defines handle(event, context), and its size. Code that fails isn't saved, and saving never runs the code.

run_automation is the dry run. It runs saved code, or code you pass inline, against a canned sample, a replay of 1 of your real events, or an event you fabricate. Nothing is applied: no request reaches Amazon, no webhook fires, and the store is a throwaway. It returns validated mutations, logs and missing_field_reads, the event keys the code read that the payload lacks. The same native schema and ownership checks run as for live output. Samples use a trusted unsaved target graph; JavaScript cannot replace its provider identity or ownership.

A typical check before activating, as your agent would run it (pseudocode):

run_automation({ code, stream_type })           // canned sample
// missing_field_reads empty? mutations as expected?
run_automation({ automation_id, event_id })     // replay a real event
run_automation({ automation_id, event_id, listing_id })  // when it reached several listings

On the demo endpoint, every write is validated and simulated. Nothing is saved or sent to Amazon.

Activation

A new automation is a draft. Activate it from your agent with update_automation and activate: true, or from the automation's page in the console.

  • 1 automation is live per event type per account. Activating another demotes the live one to a draft.
  • There is no pause. Archive an automation to stop it, with archive_automation or from the console. Restoring it brings it back as a draft.
  • Activating subscribes the event type. The subscription can take a moment; check it with list_streams.

While it runs

  • Targets. A run can patch only the listing it was built for, and change only advertising entities your user owns. Invalid output records a failed decision.
  • Native requests. Sponsored Products updates and archives use the mutation contract. Provider IDs, currency, profiles and parent references are checked. Unverified external references are rejected.
  • Stale events. An event older than one already processed for the same target and type changes nothing and runs nothing.
  • Units. Projected currency on context is in major units: 19.99 dollars. list_listings reports minor units: 1999 cents. Yen has no minor unit, so both report whole yen. Advertising budgets and bids, and FBA report quantities, arrive as decimal strings: parse them before doing arithmetic. Raw data keeps Amazon's original keys and units.
  • Sandbox. No network or file access, and caps on time and memory. See limits.

Emergency controls

Block a listing

Block a listing on its page in the console, or ask your agent to call update_listing with blocked: true. Its automations keep running, and every request they make is recorded and withheld, listing and advertising alike. Unblocking never replays them. patch_listing refuses a blocked listing.

The block is checked again under the listing's lock at submission, so a block that lands during a run still stops what that run queued.

The campaign switch

The Automation switch on a campaign's page withholds every automated change to that campaign and its ad groups, ads and targets, including keywords, whichever event asked for it. Each change is recorded as blocked and never sent, and switching back on never replays it. Automations on the campaign's own advertising events (budget usage, entity changes and hourly metrics) don't run at all.

The switch is checked again under the campaign's lock at submission, so switching off during a run still stops what that run queued.

The switch also withholds everything an automation would create inside the campaign: ad groups, ads, targets and negatives. A campaign that Pulsify created starts with its switch on, because building it requires that; switch it off like any other. Creating a campaign has no switch, since the campaign doesn't exist yet. It requires an authorized Amazon Ads connection, and a block on the listing whose event asked for it withholds it like any other request. To stop an automation from creating campaigns, archive it.

Other ways to stop

  • Archive the automation to stop it entirely.
  • Revoke an agent's access under Connected apps in Settings.
  • Set a floor and ceiling on your offer. Amazon enforces them, not Pulsify: Pulsify sends the price your code asks for. listing.floor and listing.ceiling show the bounds Amazon last reported.

The audit trail

Record What it holds Where to read it
Events Every notification Amazon sent, with its payload list_events, get_event, Activity
Automation actions What each run decided, and whether the request passed validation, failed or was blocked list_automation_actions
Mutation receipts Each listing or Ads request, its delivery state and Amazon's answer mutations in list_listings or list_ads_entities
Webhook deliveries Each POST, its response and any error Activity
Tool calls Every MCP call an agent made on your account Activity

Each record has its own lifetime. See retention.

When a run surprises you, When something goes wrong walks through the checks in order.