Overview

A campaign sandbox runs a campaign’s latest version, including changes you have not published yet. Live traffic keeps the published version. To test a draft before you publish it, send the events of a test journey, such as a share, a share click, a signup, and a conversion, to a campaign sandbox. To see what the published version does with the same events, send them to a production sandbox.

Choose a Sandbox

Sandbox	Value	Campaign version	Container
Campaign preview	`campaign_preview-<campaign id>` or `campaign_preview-<campaign id>-<journey name>`	Latest, including unpublished changes	`test`
Campaign	`campaign-<campaign id>-<container>` or `campaign-<campaign id>-<container>-<journey name>`	Latest, including unpublished changes	The container you name, such as `test`
Production	`production-<container>`, such as `production-test`	Published	The container you name

The campaign id is in the campaign’s address in My Extole, after /campaigns/. If a request sends no sandbox, Extole uses a production sandbox: production-production, or production-<container> when the request names a container. Such a request runs the published version, not your draft. The two campaign sandboxes differ in who can enter a journey and which rules run:

Campaign preview: a person can enter a journey without a referral, so you can test a friend journey without an advocate. A journey name in the value, such as FRIEND, gives that journey the highest priority. The campaign’s quality rules do not run.
Campaign: journey entry follows the campaign’s own rules. A friend enters the friend journey only through a referral, as on your live site. The campaign’s quality rules run.

Use the campaign preview sandbox to check that each part of a journey runs and renders. Use the campaign sandbox to check who enters a journey and what the quality rules stop, and send the same events to a production sandbox to compare the draft with the published version.

Send an Event to a Sandbox

Consumer Events

On the consumer API, pass the sandbox in the X-Extole-Sandbox header. Send every request of one test journey with the same header.

curl -X POST "https://<your program domain>/api/v6/events" \
     -H "Authorization: Bearer <access token>" \
     -H "Content-Type: application/json" \
     -H "X-Extole-Sandbox: campaign_preview-<campaign id>-FRIEND" \
     -d '{"event_name": "signed_up",
          "data": {"email": "friend@example.com", "shareable_code": "<advocate code>"}}'

Server Events

For an event your server sends to https://api.extole.io/v6/events, put the sandbox in the event’s data as sandbox. The X-Extole-Sandbox header applies only to the consumer API. Use a server-side access token, as in Send Events from the Partner Platform.

curl -X POST "https://api.extole.io/v6/events" \
     -H "Authorization: Bearer <server access token>" \
     -H "Content-Type: application/json" \
     -d '{"event_name": "converted",
          "data": {"email": "friend@example.com",
                   "partner_conversion_id": "<order id>",
                   "sandbox": "campaign-<campaign id>-test"}}'

A consumer event can carry sandbox in its data too. Extole ignores a value that does not match a sandbox format above and processes the event as if it named no sandbox.

See How Extole Processed an Event

To see each decision Extole made for a test event, such as which sandbox and campaign it used and which rules passed, ask for the processing log:

On the consumer API, add the X-Extole-Debug header or the debug query parameter with any value other than false or 0. The response returns the log in X-Extole-Log headers. The value trace adds timing and trace detail.
On a server call, add the X-Extole-Debug header with a level from 1 to 3, as Common Errors describes.

curl -i -X POST "https://<your program domain>/api/v6/events?debug=true" \
     -H "Authorization: Bearer <access token>" \
     -H "Content-Type: application/json" \
     -H "X-Extole-Sandbox: campaign-<campaign id>-test" \
     -d '{"event_name": "share_destination", "data": {"advocate_code": "<advocate code>"}}'

What a Test Event Does

A sandbox changes which campaign version handles the event and which container records it. The event is processed in full:

In the test container and in the campaign preview sandbox, a reward comes from your account’s test reward supplier, whatever supplier the campaign’s reward names. If your account has no test reward supplier, the reward is not issued. A rule that counts a person’s earlier rewards counts only rewards in the same container.
Emails and webhooks run as they do for a live event. Use test email addresses that you control. See Exclude Test Data from Analytics for how test containers are reported.
An event can start schedules, such as a reward’s pending period or a reminder email, which run later. After a test, cancel the schedules it started and check that each test person has no reward.
Your account’s prehandlers still apply, so a prehandler can record an event in another container than the one the sandbox names.

To check a test, read each test person’s events and rewards. A person’s steps show the container each event was recorded in.

Integration Overview

Extole AI Tools

Platform Integrations

Partners

Building Partner Integrations

Solutions

Operational Tasks

Troubleshooting

Test a Campaign Draft Over REST

Overview

Choose a Sandbox

Send an Event to a Sandbox

Consumer Events

Server Events

See How Extole Processed an Event

What a Test Event Does

​Overview

​Choose a Sandbox

​Send an Event to a Sandbox

​Consumer Events

​Server Events

​See How Extole Processed an Event

​What a Test Event Does

Overview

Choose a Sandbox

Send an Event to a Sandbox

Consumer Events

Server Events

See How Extole Processed an Event

What a Test Event Does