- In a simple case, the linked Experience will be triggered with the given options.
- A time window (
from/until) can be applied to only deliver after/before/in the specified time window. - Filters such as
onceanduse_segmentationcan fine-tune the triggering.
An Experience that is delivered to the User will show immediately and with higher priority than any other Automatic Experiences
but an Experience may not show due to the conditions added to the Delivery itself.
For example, when a Delivery uses segmentation (use_segmentation) and the segmentation does not match the
User at the time of the delivery, the Experience will not show and the Delivery is not attempted again.
Schema
Errors
- When the Experience is not live (not currently published) (
409) - When User Profile has too many pending Deliveries (
409) - When the user has not been seen by Chameleon (
422) - When the supplied dates (
fromanduntil) are out of order (422) - When the supplied dates (
fromanduntil) are not in compatible formats (422)
Limitations
Once a Delivery is marked as triggered (when at has a timestamp value) the delivery can no-longer be updated.
Pending Deliveries (yet untriggered; with a null value for the at property) are limited to 3 total per User Profile.
This limit can be changed:
- Globally to enable certain Use cases (if you’re on our Growth plan, Contact us).
- Per request, to limit to any number smaller than your global limit (defaults to
3).
delivery_ids_position to instruct us where in
the list to add this new Delivery. Use values of first, last or an integer array of indexes.
If an error occurs for a “limit reached”, either specify delivery_ids_at_limit with value of drop or
first list the Deliveries by User Profile to determine which ones to remove.
Time based limits: When using from and until the deliveries will be added to the list of pending deliveries and made
available to the client-side JavaScript but will remain undelivered until the from time is reached
or after the until time is been passed.
Managing Delivery lifecycle: When delivering for multiple use cases or when using different versions of from and until you may need to implicitly manage the “current set of deliveries for a user”. This can be done directly with the API for Removing a Delivery ↓
OR indirectly with delivery_ids_limit, delivery_ids_at_limit and delivery_ids_position. Use delivery_ids_limit=1 and delivery_ids_at_limit=drop to only keep this Delivery in the list.
Idempotency
An idempotency key is used to generate a single delivery when the delivering criteria might otherwise be met multiple times. This is different than theonce parameter because the idempotency_key operates at the moment when the Delivery is being created,
where the once is used when attempting the Delivery on the client-side.
idempotency_keyonly creates a delivery if the idempotency key has never been used before.onceonly shows the Experience if it has not been seen before.
- Create a Delivery when an Event is triggered (but only deliver the Experience once).
- Create a Delivery when an account needs to be upgraded to a new plan (but only deliver the Experience once).
- Create a Delivery when an account crosses a specific billing threshold (but only deliver the Experience once).
- Create a Delivery when you want feedback on a very specific action they took (but only deliver this type of feedback once).
Picking a good idempotency_key:
In many the use cases above simply repeat the model_id as the
idempotency_key. In other cases you may want to deliver one of many in-product Microsurveys, but if you want the
“first one” to be shown to your end-user you must pick a “campaign specific” idempotency key
such as "data-import-feedback-2029" to only ask for one Microsurvey response for the campaign you’re running to
get feedback on your hypothetical “data import flow”.
List all Deliveries
HTTP Request
GET
Create a Delivery
HTTP Request
POST
Required: One ofprofile_id,uidor
HTTP Response
Request with data (in options) intended for merge tags in the Experience
Update a Delivery
Once a Delivery is marked as triggered (when at has a timestamp value) the delivery can no-longer be updated.
HTTP Request
PATCH
Remove a Delivery
Cancel a Delivery that has yet to happen
Once a Delivery is marked as triggered (when at has a timestamp value) the delivery can no-longer be deleted.
HTTP Request
DELETE
Troubleshooting
Deliveries are used to directly trigger an Experience to one or to many users. On the next page-load, the linked Experience will be triggered with the given options. While this is generally true there are a few different conditions that must be met for the trigger to occur:- The user never loads any page
- The
fromtime has not be reached - The
untiltime has passed - The Experience is not live
use_segmentation=trueand the Audience does not currently matchonce=falseand the user has seen the Experience beforeskip_triggers=falseand the user never clicks/hovers on the configured Step triggersskip_url_match=falseand the user never loads the matching URL

