Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.flexype.io/llms.txt

Use this file to discover all available pages before exploring further.

FlexyPe webhooks are triggered at specific points in a user’s journey — browsing, checkout, and account creation. This page explains the exact conditions that fire each event and how they relate to each other.

Quick reference

EventFires whenTiming
PRODUCT_VIEWEDIdentified user views a product pageImmediately
COLLECTION_VIEWEDIdentified user views a collection pageImmediately
ABANDONED_SESSIONIdentified user browses without starting checkout, then goes inactiveAfter 15 min of inactivity
ABANDONED_CHECKOUTUser opens a checkout session and does not complete the order15 minutes after the checkout session opens
NEW_CUSTOMERFirst-time user logs in via FlexyPass and a new store account is createdOn account creation
FlexyPe must be able to identify the user via FlexyPass for any event to fire. Anonymous visitors do not trigger webhooks.

End-to-end flow

Scenario 1 — User browses, does not start checkout

1

User visits your store

FlexyPe identifies the user via the FlexyPe Network. No event fires yet.
2

User views a product page

A PRODUCT_VIEWED event fires immediately.
3

User views a collection page

A COLLECTION_VIEWED event fires immediately.
4

User goes inactive — no checkout opened

The 15-minute inactivity timer starts from the user’s last recorded activity.
5

15 minutes pass — ASR fires

An ABANDONED_SESSION webhook is sent with the user’s last known browsing state.If your endpoint returns a non-200 response, FlexyPe retries using the same event_id. See Retry logic.
If the user opens a checkout session at any point, the ABANDONED_SESSION event is not triggered — ABANDONED_CHECKOUT takes over instead.

Scenario 2 — User starts checkout, abandons mid-flow

1

User visits your store and browses

PRODUCT_VIEWED and COLLECTION_VIEWED events fire as the user browses (same as Scenario 1).
2

User opens checkout

The checkout session is created. ASR will not fire for this user. The 15-minute ACR timer starts from this moment.
3

15-minute timer starts

The timer starts from the moment the checkout session is opened — not from the user’s last activity. If the order is not completed within 15 minutes, ACR fires.
4

User progresses through checkout steps

FlexyPe tracks the user’s latest state across steps:
StateDescription
INITIATEDCheckout session opened
PHONE_ENTEREDUser verified OTP
ADDRESS_LOADEDAddress page loaded
ADDRESS_SHIPPING_SELECTEDUser selected a shipping method
Only the latest state at the time of inactivity is sent — not one event per step.
5

15 minutes pass — ACR fires

An ABANDONED_CHECKOUT webhook is sent with the user’s last recorded checkout state and a unique event_id.
6

User returns to the same session

Once a session is marked abandoned and ACR has fired, returning to that session does not trigger a new event. The session remains abandoned.
7

User completes the order

No FlexyPe webhook fires on order completion. Use Shopify webhooks to listen for completed orders.To link a Shopify order back to an ACR event, match on session ID — FlexyPe passes the same session ID to Shopify via note_attributes:
note_attributes: [
  { "name": "FlexyPe Session ID", "value": "<session_id>" }
]
This value will match payload.session_id on the corresponding ACR webhook event.

Scenario 3 — User opens a new checkout session before the previous one times out

1

User opens checkout

A checkout session is created (session A). The 15-minute ACR timer starts from this moment.
2

User closes and opens checkout again before 15 minutes elapse

Before session A’s timer expires, the user opens a new checkout session (session B).
Session A’s timer is immediately cancelled — no ABANDONED_CHECKOUT event will fire for session A. A new 15-minute timer starts from session B’s open time.
3

15 minutes pass — ACR fires for session B

If session B is not completed within 15 minutes of opening, an ABANDONED_CHECKOUT webhook fires for session B with a new event_id and session_id.

ACR — how the timer and sessions work

The ACR timer starts from session open, not from the user’s last activity. A session can only be marked abandoned once. Here is a concrete example:
TimeUser actionLatest stateEvent fired
10:00Opens checkout (session A)INITIATED
10:05Verifies OTPPHONE_ENTERED
10:10Opens new checkout (session B)INITIATEDSession A timer cancelled — no ACR for session A
10:2515 min elapsed since session B openedINITIATEDABANDONED_CHECKOUT (event_id: abc-123)
10:30Returns to session BNo new event — session already abandoned
Retried deliveries reuse the same event_id. A new session always produces a new event_id and a new session_id.

Deduplication

Retries reuse the same event_id. If your endpoint receives the same event_id twice, the second delivery is a retry — not a new event. Discard it after recording the first successful processing. See Idempotency in the overview for a code example.