Bundles

Aggregate several endpoints into one section-based response — with per-section A/B and segment targeting — so a page loads in a single call.

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:

Part	What it does
Endpoint	The endpoint whose response fills the section.
Conditions	Optional targeting — UTM params, extra query params, or a segment.
Parameter mapping	Renames incoming request params before they reach the endpoint.
Parameter config	Which 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.

Related

APIs Playground

Where the bundle and its endpoints are built.

Engagement Funnels

Funnel-scoped bundles.

Segments

Segment-based section targeting.