BillDog

Use this to A/B test paywalls: compare two or more paywalls in an app. Create a paywall A/B experiment as a DRAFT: each variant shows a different paywall at the same place in the app. The first variant is the control unless one says is_control. Traffic splits evenly unless every variant gives traffic_percent (they must add up to 100). It serves nothing until start_experiment, and every paywall in it must be published first.

create_experiment

Use this to start a mobile app paywall from a paywall template. Create a new paywall in the project from an existing template. Created as an inactive draft by default. The result's exits says whether a visitor can leave without buying: most templates draw a header close or back icon that does nothing, or hide the close; exits.fix is the update_paywall patch that wires it.

create_paywall_from_template

Create a new placement in the project. Created unlinked by default.

create_placement

Create a new BillDog project for the authenticated user with a specified name, bundle ID, and platform. With the "Create projects" permission (Sign in with BillDog), this connection then works in the new project: every other tool acts on it, and use_project switches back. Otherwise the connection stays on its current project and the result says how to reconnect — do not configure the new project until then. Check result.connection.switched.

create_project

Generate a client-safe public SDK key (bd_public_live_... or bd_public_test_...) for mobile and web apps. Never mints secret keys.

create_public_sdk_key

Use this to generate a mobile app paywall from a description, or to build one from a layout you write. For a paywall inside the user's own app, not for reading paywalled articles. Design a paywall and save it as an inactive draft. Two ways: (1) pass `recipe`: you design it yourself — a compact layout (theme, presentation, body nodes such as text, icon, feature-list, products, button) that BillDog compiles into a native paywall. Its JSON schema is below; call get_paywall_recipe_guide for the full language and design guidance. Uses no AI credit. If it does not compile, the error lists every problem; fix them and call again. (2) pass `prompt`: BillDog's AI designer (the same one as the dashboard's "Generate with AI") writes the recipe from your description and the project's offering and store listing. Uses one of the user's AI credits, charged only when a design compiles. Never write prices in text: the `products` node shows each package's real store price. Pass offering_id so the plan picker binds to that offering.

design_paywall

Return the full BillDog analytics schema — every (source, metric) pairing the project supports, with a 1-line description of what each returns. Call this once at the start of a session to know which combinations are valid.

discover_schema

Use this when adding BillDog to an iOS, Android, React Native, Flutter, Expo or web app, for paywalls, in-app purchases or analytics. Get the code to add BillDog to an app on one platform: a setup snippet carrying this project's public SDK key, and the guide to installing the SDK, identifying the signed-in user, showing a paywall, buying and restoring. Give the user this code rather than writing BillDog SDK calls from memory. If the snippet shows a placeholder, the project has no public key yet: create_public_sdk_key makes one.

get_sdk_integration_guide

How many users and evaluations got each value of a flag over the last N days (default 30, max 90), from the $feature_flag_called events the SDKs send. Name it by flag_id or key. Reads production unless sandbox is true.

get_feature_flag_results

Get a paywall by UUID or identifier: status, layouts, offering, colours and copy_outline — every text and button with its component id, current colours, whether users can see it (hidden, show_with) and whether a product list fills it (product_field), for update_paywall patch.copy, patch.colors and patch.visibility; and exits — whether a visitor can leave without buying, the header close/back icons with whether each closes or is hidden, and the patch (close_button, visibility) that fixes it. include_config returns the full draft and published configs (often hundreds of KB, too large for most agents: prefer copy_outline).

get_paywall

Use this to read a paywall A/B test: conversion, revenue per user and which variant won. Per-variant results of an experiment for its whole run: users, conversions, conversion rate, revenue per user, lift vs control, p-value and significance (p < 0.05 with 100+ users per arm), plus a verdict: winner, loser, keep_running or no_data. Reads production unless sandbox is true.

get_experiment_results

Get the full guide to writing a design_paywall `recipe`: every node type and its fields, theme tokens, icons, dynamic price values, layout and design advice.

get_paywall_recipe_guide

Get project metadata including bundle ID, package name, and registered domains.

get_project

Use this to check whether an iOS, Android, React Native, Flutter, Expo or web app is sending events and purchases to BillDog. Is the app sending data? For the last window_hours (default 24): events by name, purchases and session replays, split into sandbox and production, with has_traffic for each.

get_recent_sdk_activity

Re-run a saved view and return its results. Equivalent to opening that report in the dashboard with the saved filters/range applied. Reads production data unless sandbox is true.

get_saved_view_results

Link one or more offerings to a placement with priority order (replaces its links). On a live project (a production purchase, or 10+ production customers, in the last 30 days; sample projects never count) the change waits for an owner or admin to approve it: the result is awaiting_approval with an approve_url to pass on.

link_placement

Use this to see the mobile app paywalls in the connected project. List all paywalls in this project, including active state, wall type, and publication timestamps.

list_paywalls

List all marketing and engagement campaigns configured for this project.

list_campaigns

List saved cohorts for this project. Each cohort has a definition (event-frequency / property / behavioral predicate) and a member_count. Pass a cohort id as the segment_id param to run_analytics_query to scope a report to that cohort.

list_cohorts

List all entitlements in this project and the product IDs associated with each entitlement.

list_entitlements

List the event names this project received in the last `days` days (default 30), most frequent first, with each one's count and unique users. Useful when the user asks about an event by approximate name and you need the canonical one. Reads production data unless sandbox is true.

list_event_names

List the project's experiments with their status, what devices are served now (variants, the shipped winner, or the control only), and each variant's paywall and traffic share.

list_experiments

List the project's feature flags: key, on/off, rollout percentage, variants, and whether it has release conditions (audience rules, edited in the dashboard).

list_feature_flags

Use this to see the in-app purchases and subscriptions set up for an app. List all products configured in this project's catalog, including their identifiers, product types, subscription durations, and store mapping IDs.

list_products

List all customer onboarding and engagement journeys with their sequence of steps.

list_journeys

List the project's message templates (push, in-app, email, SMS) with their title and body, as the dashboard Templates library shows them. Deleted templates are excluded.

list_message_templates

List all offerings in this project, showing their packages, attached products, and default/current status.

list_offerings

Use this to browse paywall templates by app category before building a paywall. List available paywall and onboarding templates from the BillDog template catalog.

list_templates

List all placements in this project, including access gating settings and linked offerings.

list_placements

List all BillDog projects accessible to the authenticated user, identifying the current active project, bundle ID, and platform.

list_projects

List saved analytics views for this project, each with what it asks (source, metric, dims, filters, date range, segment). Use get_saved_view_results to run one. Only views the user can see (shared with the project, or their own). pillar_id narrows to one area (revenue, product, surveys, …).

list_saved_views

List all multi-page surveys and micro-survey walls configured for this project.

list_surveys

Add or remove packages within an existing offering. A new package goes after the last one unless position is given. action "retype" changes a package's package_type (package_id + package_type), e.g. a monthly plan stored as "custom", which offering.monthly cannot see. If customers can reach the offering (it is current, linked to a placement, or a published paywall uses it) and the project is live, the change waits for an owner or admin to approve it (awaiting_approval, with an approve_url to pass on). Live means a production purchase, or 10+ production customers, in the last 30 days; sample projects never count.

manage_offering_packages

Evaluate paywall publish gate (validating components, bindings, offerings) and generate a secure short-lived preview link and token. store_warnings (when present) lists products a platform the project targets will not show because they have no App Store / Google Play product id; it does not block publishing.

preview_paywall

Use this to debug which paywall and offering an app will show at a placement. Dry-run preview of what a client SDK receives when resolving a placement: an active campaign first (a holdout serves nothing), else the offering linked to the placement, else nothing. Returns served_by, the matched offering, packages, and assigned paywall, plus any running or shipped experiment on that paywall (`experiments`, with each arm's traffic and paywall): while one runs, assigned_paywall is only what its control sees.

resolve_placement_preview

Publish a draft paywall to make it active for SDK delivery. Validates paywall before publishing. On a live project (a production purchase, or 10+ production customers, in the last 30 days; sample projects never count) the change waits for an owner or admin to approve it: the result is awaiting_approval with an approve_url to pass on. The approval publishes the draft as it was when you asked; edit it afterwards and you must ask again. store_warnings (when present) lists products a platform the project targets will not show because they have no App Store / Google Play product id: tell the user, it does not block.

publish_paywall

Use this for subscription analytics and mobile app analytics in the connected project: revenue, MRR movement, churn, active subscriptions, retention, funnels and paywall conversion. Run a single analytics report. Returns a ReportResult envelope with columns + rows + optional totals. Properties named like personal data (email, phone, name, token) are refused and email addresses in results are hidden. Available sources: events, revenue, cohorts, notifications, surveys, virtual_currency, subscriptions, paywalls, offerings, products, campaigns, experiments, journeys, customers. Available metrics: totals, timeseries, breakdown, funnel, retention, distribution, top_n, flow, compare, mrr_movement, ab_results, stickiness. Call discover_schema first if you need to know which (source, metric) pairings are supported. Reads production data unless sandbox is true; the result says which environment it read.

run_analytics_query

Make an offering the project current offering (the others stop being current, atomically). On a live project (a production purchase, or 10+ production customers, in the last 30 days; sample projects never count) the change waits for an owner or admin to approve it: the result is awaiting_approval with an approve_url to pass on.

set_current_offering

Set the explicit list of product IDs granting an entitlement (replaces the list; only the links that change are touched). On a live project, removing a product (its buyers lose the entitlement) waits for an owner or admin to approve.

set_entitlement_products

Start (or resume) an experiment: users who reach its paywall are split between the variants. Refused unless it has 2+ variants whose traffic adds up to 100, exactly one control, every paywall published, and no other running experiment on the same paywall. On a live project (a production purchase, or 10+ production customers, in the last 30 days; sample projects never count) it waits for an owner or admin to approve it: the result is awaiting_approval with an approve_url to pass on.

start_experiment