Skip to main content
Rabbithole campaigns expose a public REST API and a TypeScript SDK for building campaign experiences inside your own product. Show a live reward APR next to your pool, surface what a user has earned, and let them claim without ever leaving your app. This is a read and claim surface. It never takes custody of funds, and the only server-side write is a referral bind, which the user signs. Claims and deposits are transactions your users sign.
Campaigns are not self-serve today. The Rabbithole team scopes, integrates, and deploys each one (see Launch a Campaign). These pages are for integrating a campaign that already exists.
Campaign already live? Go straight to the Quickstart.

​
Get Access

There is less to arrange than you might expect.
  1. A live campaign. Rewards have to be running against a vault, pool, or token before there is anything to display. Start that conversation with the team on Discord.
  2. A partner refId. An attribution ID that Rabbithole assigns manually. The SDK sends it as the x-boost-ref-id header on every request so campaign usage can be credited to your integration. It is not authentication and not a secret.
  3. Nothing else. There is no API key, no signup, and no signed request. Every endpoint in these docs is public.
Ask for a refId in your shared partner channel with the Rabbithole team, or on Discord, before you ship. Everything works without one; you just lose the attribution.

​
What You Can Build

Each of these is a complete React component for a Next.js, wagmi, and viem stack. Copy it, point it at your campaign, and ship. The guide behind each one explains the endpoints it calls.

Reward Badge

Your campaign’s reward APR, time left, and what the connected wallet has earned, next to your own deposit form.

Opportunities List

A table of live campaigns with reward APR, TVL, and time remaining, for your own pools or a whole chain.

Rewards Panel

What the connected wallet has earned and can claim, across every campaign it has entered.

Claim Button

Switches chain, simulates, submits, waits for the receipt, and updates the UI safely.
Start with Project Setup for the shared client, providers, and formatting helpers. Smaller pieces, such as a campaign status line or open-ended runway, are on Recipes. Prefer the endpoint-level view? The same outcomes are covered as guides, with curl alongside TypeScript. Running a campaign with a referral pool? Add Referrals covers binding referees from your links, showing referrers what they have earned, and claiming their payouts.

​
SDK or Raw REST

Both are first-class and hit the same endpoints. The SDK converts decimal strings to bigint, parses timestamps, and ships claim helpers that build and submit the transaction. Raw REST works from any language, but you own the parsing and the calldata encoding.
The production base URL is https://api-tbi.boost.xyz. A staging host, https://api-tbi-staging.boost.xyz, runs the same API against test campaigns that pay on Base Sepolia; see Building Against Staging.

​
Shared Fundamentals

These apply across every guide:
  • Campaigns, IDs, and Chains: the compound campaign key, the event-versus-reward-chain rule, lifecycle status, and campaign modes as data.
  • How Claiming Works: merkle roots, cumulative amounts, and why earned and claimable are different numbers.
  • Data Conventions: wire formats, bigint amounts, pagination, caching, and rate limits.
  • How Referrals Work: global binds, estimated versus final earnings, and one-shot payouts.
  • TypeScript SDK: install, configuration, and the full method surface.
  • Errors: the shared error envelope and the typed SDK classes.
  • Contracts: the TBI Manager, the claim signature, and every revert selector.
  • API Reference: every endpoint, parameter, and response schema, generated from the live OpenAPI spec.

​
Keep Exploring

Quickstart

Discover, read, and claim in five steps.

How It Works

The campaign model behind the API, from goal to earning to claim.