Skip to main content

Overview

Config Bundles are versioned JSON payloads that contain all the configuration the SDK needs to render onboarding flows, paywalls, feature flags, remote config, and in-app messages. The SDK downloads the bundle at launch and caches it locally, polling for updates periodically.

Endpoints

Download Latest Bundle

Authentication: SDK Key (x-api-key header) Returns the full config bundle including all content. Use this when the SDK needs the complete configuration. Response: The bundle is wrapped in a top-level data object.

Check Bundle Version

Authentication: SDK Key (x-api-key header) Lightweight version check that returns metadata without the full content payload. Use this for polling. Response: Metadata is wrapped in a top-level data object.
This endpoint returns only metadata (no content field), making it ideal for frequent polling without unnecessary bandwidth usage.

Force Regenerate Bundle

Authentication: Customer JWT (Authorization: Bearer header) Forces the server to regenerate the config bundle. Returns the newly generated bundle. Use this after making configuration changes that you want to push immediately. Response: HTTP 201 Created. Same shape as the Download endpoint — the bundle wrapped in a top-level data object.

Bundle Version History

Authentication: Customer JWT (Authorization: Bearer header) Returns a paginated list of previous bundle versions. Query parameters:

SDK Bootstrap

Authentication: SDK Key (x-api-key header) Returns the org/app context and runtime settings the SDK needs to initialize. Rate-limited to 60 requests/minute per key; the response is client-cacheable for 24 hours. Response:
For a tenant whose billing has lapsed or whose account has been locked, the response also carries a runtime_lock object; the SDK reads it and enters a safe read-only mode automatically — your app code does not need to handle it.

Bundle Content Schema

The content field of the config bundle contains all published configurations organized by type:

Content Types


SDK Polling Pattern

The recommended SDK integration pattern minimizes bandwidth while keeping configuration fresh:

Auto-Generation

The config bundle is automatically regenerated when any of the following actions occur in the dashboard:
  • An onboarding flow is published or unpublished
  • A paywall is published or updated
  • An in-app message is published or updated
  • Remote config or feature flags are modified
Manual regeneration via POST /config-bundle/generate is available but rarely needed. The platform handles regeneration automatically on publish.

CI/CD Integration

For zero-latency first launch, download the config bundle at build time and embed it as a fallback:
The embedded bundle is a fallback only. The SDK will always attempt to fetch the latest bundle from the server on launch. Ensure your CI pipeline runs frequently enough that the embedded bundle does not become stale.
Your config bundle integration is working correctly when the SDK logs ConfigBundle loaded (version: N) during initialization and you see your published onboarding flows or paywalls rendering on device.