One integration. Every surface.
The same services the app runs on, available to you: the wallet, the loyalty ledger, offers, supply, and one basket that settles across all of it. Take the pieces you want and render the rest yourself.
One sign-in, and the memberships behind it, held with consent.
Balances, earn and burn at the transaction, value moved between programmes.
Offers by place and moment, and the content behind them.
Stays, seats, transfers, tables and experiences, as one inventory.
One basket, split bills, points and cash in one payment.
The same services inside Claude and ChatGPT.
A member’s wallet in your app, in four calls.
The shortest route from keys to a first response: authenticate your system, open a session the member consents to, and read their balances. Tap a step to see the call.
- 01Get your keys
Sandbox keys arrive with access. Live keys follow once the integration is signed off.
- 02Authenticate
Exchange your client credentials for an access token, scoped to the services you use.
- 03Open a member session
The member approves exactly what you asked for. You receive a member token for those scopes only.
- 04Read the wallet
Balances, programmes and what each one gives the member right now.
One guide for each job.
Each guide takes one journey from start to finish, with the calls, the webhooks and the edge cases. They are issued with the reference.
Balances, programmes and entitlements for a signed-in member.
GET /v1/wallets/mePost the earn at the transaction, to your programme’s ledger.
POST /v1/earn-eventsPoints, card or both, in the same payment.
POST /v1/baskets/{id}/paySearch, hold and confirm, with the member’s status applied.
POST /v1/searchA table held against the plan, settled when the bill comes.
POST /v1/holdsAn offer to the right members, at the moment it applies, with a cap.
POST /v1/offersGroups and opportunities, never names, for your own programme.
GET /v1/signalsWhat to do when a member narrows or withdraws a permission.
consent.revokedSigned events for orders, points, offers and consent.
POST your-endpointYour content, events and benefits into your space in the app.
PUT /v1/labels/{id}/contentResources, by service.
REST over HTTPS, JSON in and out, one base URL per environment. A selection of the resources in each service; the reference covers every field, error and event.
Members, sessions and consents, and the wallet behind them.
- POST/v1/member-sessions
- GET/v1/wallets/me
- GET/v1/consents
- DELETE/v1/consents/{id}
Programmes, earn and burn, and SwapX between programmes.
- GET/v1/programmes
- POST/v1/earn-events
- POST/v1/swaps/quotes
- POST/v1/swaps
Offers, redemptions, signals and content.
- POST/v1/offers
- GET/v1/offers/{id}/results
- POST/v1/redemptions
- GET/v1/signals
Search, holds and orders across stays, flights, transfers, tables and experiences.
- POST/v1/search
- POST/v1/holds
- POST/v1/orders
- GET/v1/orders/{id}
One basket across suppliers, paid once, split when needed.
- POST/v1/baskets
- POST/v1/baskets/{id}/items
- POST/v1/baskets/{id}/pay
- POST/v1/baskets/{id}/split
The MCP server assistants call, with identity and consent carried through.
- MCPsearch_supply
- MCPhold_booking
- MCPpay_basket
- MCPread_wallet
How every call behaves.
The same conventions across every service, so the second integration is quicker than the first.
- AuthenticationOAuth 2.0 client credentials for your systems, and member tokens scoped by consent. Keys are held per environment.
- EnvironmentsA sandbox with synthetic members, supply and settlement, and live. The base URL is the only thing that changes.
- VersioningDated versions, set per request in the
BLACKBOOK-Versionheader, so an upgrade happens when you choose. - IdempotencyAn
Idempotency-Keyon every write, so a retry never books or pays twice. - PaginationCursor-based, with
limitandafteron every list. - ErrorsJSON with a type, a code, a readable message and a request id to quote to support.
- Rate limitsPer key, with the remaining allowance returned in the response headers.
- WebhooksSigned events, retried until acknowledged:
order.confirmed,points.posted,offer.redeemed,consent.revokedand more.
Drop in the pieces, or call them yourself.
Native components for the app you already publish, themed to your brand, and server libraries for the calls behind them.
The wallet, offers, basket and checkout as native modules.
SwiftThe same modules for Android apps.
KotlinDrop-in elements for the wallet, offers and basket on your own site.
<bb-wallet>Typed clients for the API, with webhook signature checks built in.
Node · PythonThe services as tools for Claude, ChatGPT and other assistants, under your brand.
mcp.blackbookapp.coSynthetic members, supply and settlement to build and test against.
sandboxEvery call carries the member’s permission.
Members are anonymous to us and to you until they choose otherwise. A member token only ever carries the scopes the member approved, and every call is logged against the consent it was made under. How identity and privacy work.
wallet:readBalances, programmes and entitlementswallet:spendPoints and card at checkout, up to the limit the member setsupply:bookHolds and orders on the member’s behalfoffers:deliverOffers to members who have switched them onidentity:revealThe member’s name and details, for one purpose, for a set time
// The member narrowed a permission. Stop using the scope at once. { "type": "consent.revoked", "consent": "cn_4712_08", "member": "mbr_7f2a", "scopes": ["wallet:spend"], "at": "2027-03-12T09:41:22Z" }
The short answers.
Do we have to replace anything?
No. Whatever you run today keeps running — the loyalty engine, the reservation system, the policy platform, the membership database, the CMS. We connect around it.
Who holds the customer?
You do, whether you call them a member, a cardholder, a guest, a policyholder or a subscriber. We work on a token you mint and resolve; identity, contact details and the send button stay on your side.
Can we bring our own inventory or offers?
Yes. Whatever you already sell or already give away — rooms, seats, cover, court time, tickets, subscriber benefits — sits alongside ours in the same basket and settles the same way. Commercial terms vary with what each side brings, so the split reflects it and the arrangement is worth doing for both of us.
What about payments?
Orchestration sits under the basket — settlement across multiple suppliers, split bills, and points and cash in the same transaction. Card data is tokenised and never held by us.
How long does a first integration take?
Weeks, not quarters, for one service against one use case. Most partners start with a single flow and widen from there.
We are not in travel. Is this for us?
Yes. Travel is the first place the wallet gets used, not the limit of it. Card programmes, clubs, insurers, publishers and retailers all build on the same services — identity, a currency, offers, a basket that settles.
Where does it run?
A dedicated environment per partner, in the region you require, encrypted in transit and at rest, with a full audit trail.
Where are the docs?
With access. The reference, the SDKs and the keys arrive together, once we know which services you want.
Tell us what you want to build.
A short note is enough. We come back with the reference, sandbox keys for the services you need, and someone technical on the other end of it.