Launch your first trigger

1. Agree on the outcome and prerequisites

Your first success is one expected event accepted by your receiver, with evidence that a visitor who converts is excluded. You need an AXO site you can edit and an implementer who can prepare the receiver and create the trigger in its paused state. The qualifying case alone takes at least 60 minutes plus processing time with these settings; the full verification takes longer.

If test access is unavailable, you can prepare the template and paused configuration, but leave activation pending. Ask AXO for the missing environment and validation evidence before proceeding.

If your website only records outbound clicks, choose a click-based workflow with a suitable outcome. Do not substitute a click for a purchase or assume AXO can observe activity on another company's checkout.

2. Prepare the destination and payload

1. Follow Outbound webhook setup to save the receiver URL and signing secret. For a trigger-only connection, clear every Events to forward checkbox before saving so generic integration subscriptions do not create a second delivery path. Pause this dedicated connection after saving. If you reopen its configuration, check the event selections again before saving.
2. Open Triggers, choose New Trigger → Custom / advanced, and select the webhook integration. Under Payload template, choose + New.
3. Name the template Cart follow-up handoff, select JSON format, and paste the body below. Choose Preview rendered body. Check that the result is valid JSON with a profile ID and trigger ID.
4. Choose Create template to save the template, then Cancel the trigger form. Saving a template does not create a trigger. Use list_integrations and list_trigger_templates on your site-scoped AXO connection to read the saved IDs; match the receiver URL and template name before using them.

{
  "event": "cart_followup_due",
  "trigger_id": "{{trigger.id}}",
  "profile_id": "{{profile.id}}",
  "sent_at": "{{now}}"
}

The receiver must verify X-VibeTag-Signature as the hexadecimal HMAC-SHA256 of the exact request body using the configured secret. Trigger payload delivery sends this rendered JSON directly, with X-VibeTag-Trigger and X-VibeTag-Identifier-Type headers. It differs from the generic integration webhook envelope. Have the receiver durably record an accepted request before returning a successful response.

Preview rendered body does not send a request to the receiver. The separate integration Send test event uses an unsigned ping and cannot validate this signed trigger payload. Keep signature verification enabled.

3. Have an implementer create the paused trigger

The dashboard's Create trigger button enables the trigger immediately, and the current create_trigger MCP tool does not expose an enabled option. The API supports enabled: false. Use this developer step to preserve a review period before activation.

The example uses the implementer's signed-in dashboard session and an explicit site ID. The server checks account access to that site. Obtain the site ID from get_site_config and confirm its name and domain. Run the request only on the AXO dashboard origin after selecting that account, reviewing the request, and replacing all three IDs. A public tag credential or a Pulse bearer key is not a substitute for the authenticated session in this example. If the session lacks access, resolve that access with the account owner.

// Developer: run from the signed-in AXO dashboard origin.
// Replace the site, integration, and template IDs with the verified values.
const siteId = 'REPLACE_WITH_SITE_ID';
const body = {
  "name": "Cart follow-up handoff",
  "enabled": false,
  "mode": "dormancy",
  "watch_event": "add_to_cart",
  "cancel_event": "conversion",
  "identifier_type": "profile_id",
  "delay_ms": 3600000,
  "window_ms": 86400000,
  "cooldown_per_profile_ms": 86400000,
  "skip_if_converted_within_days": 3,
  "destinations": [
    {
      "integration_id": "REPLACE_WITH_INTEGRATION_ID",
      "payload_template_id": "REPLACE_WITH_TEMPLATE_ID",
      "dispatch": {
        "kind": "payload"
      }
    }
  ]
};
const response = await fetch('/api/triggers', {
  method: 'POST',
  credentials: 'same-origin',
  headers: { 'Content-Type': 'application/json', 'x-site-id': siteId },
  body: JSON.stringify(body),
});
const result = await response.json();
if (!response.ok) throw new Error(JSON.stringify(result));
console.log(result); // { ok: true, id: 'trg_...' }

Have the implementer return the saved trigger ID, site ID, destination, template, and enabled state. Refresh Triggers and confirm the row says PAUSED. If the create request times out, inspect the list before retrying; creating a second trigger can produce duplicate delivery.

4. Verify the normal event path

Have the implementer create a separate test copy of these settings in the isolated environment and enable that copy and its controlled destination there. Keep the production trigger paused. Use distinct controlled profiles for each case, check the source event and candidate state, retain receiver logs, and pause the test copy when finished. Do not use Test fire to prove these conditions: it is a direct send that bypasses normal eligibility and can dispatch even when the trigger or integration is paused.

Read the saved settings with get_trigger. Use get_events to record each source event's ID, type, timestamp, and session ID, then match that session to get_profile's session list for the controlled profile. Use list_trigger_fires with the trigger ID, or the row's History, for success, error, holdout, and cooldown evidence. Follow next_cursor when the required time range spans more than one page.

Candidate state and event-processing progress have no self-service read screen or MCP tool in this workflow. Ask AXO for an operator check using the test site ID, trigger ID, profile IDs, event IDs, and timestamps. Request candidate eligibility, cancellation and expiry times, plus confirmation that ingestion and evaluation processed the relevant events. An empty History is not a substitute. If that evidence is unavailable, mark the affected case unverified and keep production paused.

Verify the cart follow-up configuration in our isolated environment. Show the saved settings, the source event and profile for each case, the candidate state, the History result, and the matching receiver record or confirmed absence. Keep the production trigger paused and report any step you could not verify.

The configured ingest schedule runs every five minutes and evaluation every minute; backlog can add delay. If no event appears, first establish whether the source was collected, linked to a profile, and processed. Repeated clicking or Test fire can hide the original problem.

Receiver acceptance proves a handoff. Any downstream business action requires a separate confirmation. Keep synthetic activity out of customer results. If the environment or evidence is unavailable, leave the trigger paused and record exactly which checks remain unverified.

5. Enable delivery deliberately

1. Review the saved settings and verification evidence with the person responsible for the receiver. Confirm the receiver's intended production behavior and data use.
2. Obtain AXO's operator check of pending candidates and event-processing progress before activation. Resume can release eligible stored work. If stale or already-converted work remains, keep the trigger paused and follow the recovery step below.
3. Resume the dedicated integration in Integrations. Then choose Resume on the trigger and confirm LIVE.
4. Observe authorized real activity through History and the receiver's records. Check the first expected handoff before enabling any additional downstream automation.

Trigger activation is independent of website content publishing. A site's Pre-launch mode and Review before publishing do not provide a staging gate for these sends.

6. Stop or repair the workflow

Choose Pause on the trigger to prevent new candidate selection. AXO evaluation already in flight can finish and send after Pause; ask the operator to check in-flight work before declaring the stop verified. Pause the dedicated integration when you also need to stop its other normal outbound paths. Already dispatched requests and receiver automations need to be stopped at the receiving system. Test fire remains a direct-send action even while paused.

Pausing does not clear the candidate queue. Cancel events processed while a trigger is paused do not cancel its pending candidates. Keep it paused when stale or already-converted work is found. There is no self-service queue-clear action in this workflow. Ask AXO for the latest pending expiry time; existing candidates become ineligible after expiry. Wait past that time and request a fresh check of pending candidates and unprocessed source events before resuming. If the operator cannot confirm that resumed processing is appropriate, leave the trigger paused and ask AXO to resolve the queued work. Do not use Delete as a queue-clear shortcut; it removes trigger history.

Use the trigger diagnosis table to distinguish absent source events, skipped eligibility, failed dispatch, and a downstream failure. Check receiver records before retrying an uncertain request, and make the receiver handle duplicates safely.

7. Adapt it to your next use case

For a lifecycle email, choose a supported email destination, provide the required email identifier, verify applicable consent and subscription rules, and use its payload or Native format. The webhook in this tutorial is treated as an operational destination; it does not establish marketing consent or supply an email address.

For a narrower audience, add explicit event criteria through the API or MCP and verify a matching and nonmatching case. For a multi-step sequence, review cancellation, cooldown, and destination effects at each step before chaining triggers. See Trigger setup and operation and Performance and lift.