Skip to main content

​
Overview

A Bundle aggregates the responses of several endpoints into a single, section-based payload. Instead of the client making one call per widget on a page, it calls one bundle endpoint and receives every section’s data in a single response. For the bigger picture, see Core concepts.

​
Where to find it

Bundles are managed through the APIs Playground: a bundle is owned by an endpoint built from the Bundle library.

​
Sections & configurations

A bundle is a list of sections (one per widget/area of the page). Each section holds one or more configurations, and a configuration is:
PartWhat it does
EndpointThe endpoint whose response fills the section.
ConditionsOptional targeting — UTM params, extra query params, or a segment.
Parameter mappingRenames incoming request params before they reach the endpoint.
Parameter configWhich params are exposed (caller can override) vs fixed to a default.

​
Per-section targeting

When a section has several configurations, the bundle picks the best match per section, in this priority order:
  1. Params match — a configuration whose UTM / extra-param conditions all match the request.
  2. Segment match — a configuration whose segment is one the contact belongs to.
  3. Fallback — the first configuration (the default, usually with no conditions).
This is what powers A/B testing and per-segment personalization within a single section.

​
Parameters

Per configuration, parameters are handled in two steps:
  • Mapping — rename an incoming request param to the name the endpoint expects.
  • Config — for each parameter: exposed uses the caller’s value (or a default if absent); not exposed always uses the default (the caller can’t override it). Params not listed pass through.

​
Authentication

A bundle’s auth requirement is derived: it requires authentication if any referenced endpoint does. You don’t set it directly — it follows the strictest section endpoint.

​
Bundle endpoint vs section endpoints

There are two endpoint roles:
  • The bundle endpoint — the entry point that owns the bundle (built from the Bundle library). Creating, renaming, or deleting it creates, syncs, or deletes the bundle.
  • The section endpoints — the endpoints each section calls to fetch its data. Only enabled endpoints are executed.
A bundle can also be scoped to a funnel; a global bundle and a funnel-scoped one can share a slug.

​
Example

A landing page with a hero (A/B by UTM) and a feed (personalized by segment), fetched in one call. A bundle is called like any endpoint, at /api/v1/endpoints/{slug} — where the slug is the bundle endpoint’s slug: 
GET /…/api/v1/endpoints/home-page?utm_variant=b
The response returns both sections resolved: hero uses the b variant (UTM match), and feed uses the VIP endpoint if the contact is in that segment — otherwise the default feed.

​
Seeds

Seeds support for bundles is coming soon.

​
Governance & permissions

Only a super admin or Master can create, edit, and delete bundles.

​
API access

The User API manages bundles and their sections; the Contact API resolves a bundle by slug and returns every section’s response (with an api-key). See the API reference.

APIs Playground

Where the bundle and its endpoints are built.

Engagement Funnels

Funnel-scoped bundles.

Segments

Segment-based section targeting.