Skip to main content
ElasticFunnels provides two ways to display order information on your pages: the <order> HTML tag (for the visual builder) and backend functions like getOrders() / getOrder() / getSessionOrders() / getPurchasedProducts() for code-based pages. Both retrieve data from the customer’s purchase history.

Two Approaches

For a member-area page that needs each purchased product with its included bonuses and download links, prefer getPurchasedProducts() over manually joining getOrders() + getAllProducts() + getBonusProducts() on the client. It returns a flat list with same-order bonuses already attached and a pre-rolled-up downloads[] array (each entry tagged with kind). See the data-functions reference and the “My Library” pattern for examples.

Using the <order> Tag

The <order> tag is processed server-side and automatically loops through the customer’s purchase history. See the full Order Tag reference for all placeholders and options.

Using getOrders() in Backend Scripts

For code-based pages (.ef files or pages with backend scripts), getOrders() gives you full control over the layout. It returns an array of order objects you can loop through with @foreach.

Basic Usage

Parameters (getOrders)

Alternative: Inline Call

You can also call getOrders() directly in a @set directive without a backend script block:

Using getOrder() for a Single Order Detail Page

When you already know which order to show, use getOrder(code) instead of loading the full order list and searching manually. This is ideal for pages like /members-order?order=EF-12345. getOrder() uses the same customer/session scope as getOrders(), so it only returns orders that belong to the currently logged-in customer for that brand.

Example: Single order page

What code can be

getOrder(code) matches any of these values within the current customer’s orders:
  • order_number / public order ID
  • internal order_id
  • conversion code

Parameters

For an order detail page, prefer getOrder(request.query.order) over getOrders() plus a manual loop/filter. It is shorter, clearer, and communicates intent directly.

Fulfillment status and shipments

Use getOrderFulfillment(code) on an order detail page to show 3PL fulfillment status and timestamps. Responses are allowlisted (no raw provider payloads). Use getOrderFulfillments() with no arguments to list every tracking row across all of the customer’s orders—each row includes order_number so you can link to /members-order?order=…. For a single order, order.tracking from getOrder / getOrders is often enough for carrier links. The fulfillment helpers add lifecycle status (getOrderFulfillment) and a cross-order shipment list (getOrderFulfillments).

Example: order detail with fulfillment summary

Example: all shipments for the account

Order Object Structure

Each order returned by getOrders() or getOrder() contains:

Displaying Tracking Information

If your orders have physical shipments, tracking information is automatically extracted from fulfillment data. The system checks multiple sources for tracking numbers:
  1. Direct conversion fields (tracking_number, tracking_url)
  2. Fulfillment provider response data
  3. Fulfillment order data
Carriers are auto-detected from tracking number patterns (USPS, FedEx, UPS, DHL, UniUni). If no tracking URL is provided, a universal tracking link via 17track.net is generated. order.tracking is always an array. When the order has not yet been fulfilled it is empty ([]). Use order.shipping_address as the signal that the order contains a physical product — if there is a shipping address but no tracking yet, show a “being processed” message.

Example: Physical order with processing/tracking states

The key pattern:
  • order.shipping_address is present → physical product → show the shipping address block.
  • Inside that block, order.tracking.length gt 0 → shipment is on the way → show carrier + tracking link.
  • Otherwise → show “Your order is being processed.”
Tracking numbers are auto-linked to 17track.net when no carrier URL is provided. The carrier is auto-detected from the number pattern (USPS, UPS, FedEx, DHL, UniUni). You do not need to map carriers yourself.

getSessionOrders() — Current Session Orders

getSessionOrders() returns only the orders that were placed during the current browser session. Unlike getOrders(), which returns the full purchase history for a customer, getSessionOrders() is scoped to the active checkout session — making it the right choice for thank-you pages where you only want to show what was just bought. The order list is served from the session itself — every charge (the main order, order bumps, and each one-click upsell/downsell) is recorded the instant it is processed. That means getSessionOrders() returns the complete set of orders on the very first page load, including upsells accepted seconds earlier. No indexing wait and no page refresh are required. By default it returns all orders from the current session. Pass an optional limit to cap the count.

Parameters (getSessionOrders)

Basic Usage

Prefer getSessionOrders() over getOrders('newest', 1) on thank-you pages. getOrders() reads from the search index, so a customer with an existing purchase history could see a previous order — or miss a just-accepted upsell — until the new conversions are indexed. getSessionOrders() reads from the current session, so it shows exactly what was just purchased, complete and immediately.

Thank You Pages

Thank-you pages are a natural place to show order details. Since the customer is auto-authenticated from checkout, order data is available immediately. Use getSessionOrders() on thank-you pages so that only the orders from the current checkout session are shown — not the customer’s full history.

Example: Thank You Page with Order Summary

No auto-refresh or retry timer is needed. getSessionOrders() serves the current session’s orders from the session, so every order — including all upsells and bumps — is present on the first page load, with each order’s primary product already shown. Full line-item detail (for example, an order bump attached to the main order) may enrich a moment later once the conversion finishes indexing, but the order rows and their primary products never wait on the index. Avoid a JavaScript refresh loop: it only re-runs a query that already returns the complete list.

Customer Data Outside of Orders

You can also display customer information directly using the customer template object (populated from the session):
The customer object includes: name, email, first_name, last_name, phone, order_id, order_ids, and full billing/shipping address fields. It is automatically available in every backend script and template — no function call needed.

Order Grouping

Orders are grouped intelligently — multiple conversions from the same purchase session (e.g., a main product and an upsell bought in the same checkout flow) are combined into a single order. The grouping logic uses:
  • Session ID matching — Conversions from the same browser session
  • Time proximity — Conversions within 6 hours of each other
This means an upsell purchased immediately after the main product shows under the same order, not as a separate entry.

Order Tag Reference

Full reference for the <order> HTML tag and all placeholders

Backend Scripts

Learn about backend scripts and available functions

Template Engine Syntax

Filters, conditionals, and loops for displaying data

Thank You Pages

Best practices for post-purchase confirmation pages