Skip to main content
  • 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 once and use_segmentation can 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 (from and until) are out of order (422)
  • When the supplied dates (from and until) 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).
A User Profile that already has 2 pending Deliveries requires a special parameter 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 the once 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_key only creates a delivery if the idempotency key has never been used before.
  • once only shows the Experience if it has not been seen before.
In terms of use cases:
  • 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
Mirrors to the options for Showing an Experience via JavaScript
Required: One of profile_id, uid or email

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 from time has not be reached
  • The until time has passed
  • The Experience is not live
  • use_segmentation=true and the Audience does not currently match
  • once=false and the user has seen the Experience before
  • skip_triggers=false and the user never clicks/hovers on the configured Step triggers
  • skip_url_match=false and the user never loads the matching URL