Integration layer
Three supported ways to run a partner-funded discount on Brizz. This guide is for your engineering team: the flow, the exact requirements, and the endpoints, payloads and failure behaviour for each. Brizz absorbs the discount at checkout — the event organiser's payout is never touched.
A campaign defines the discount, who can use it, the budget cap and the events it covers. Customers redeem codes. The only decision your team makes is who holds the codes, and how Brizz confirms one is valid. That gives three models. They are independent — pick the one that matches how your system works.
You pre-fund a campaign; Brizz generates and distributes the codes. Checkout matches them locally.
You build nothing
DetailsYou already have codes. Hand them to Brizz by CSV or one API call. Checkout is still local.
You build a CSV, or one API call
DetailsYour codes stay in your system. Brizz calls your endpoint live at checkout to confirm each one.
You build an HTTPS endpoint
Details| A · Brizz mints | B · You upload | C · Real-time | |
|---|---|---|---|
| Who generates codes | Brizz | You | You |
| Code list shared with Brizz | n/a | Yes, in full | No — only codes presented |
| Checkout latency | Local, instant | Local, instant | One live call to you |
| You operate a service | No | No | Yes |
| If your systems are down | No effect | No effect | Your codes stop discounting |
| Reconciliation | API · webhooks · reports | API · webhooks · reports | Live result + your logs |
| Best when | Brizz distributes | You have a fixed batch | Your app mints per signup |
Which is the pay-per-signup loop?
“Pre-fund → your app issues a coupon at signup → Brizz validates it” is Model C. If you'd rather Brizz hand out codes and simply report redemptions back, that's A or B — considerably less engineering, and no live service to run. You can also mix: a printed-flyer batch through B alongside an app-issued flow through C.
A note on Model C
Model C puts your service inside a live checkout. If your system can hand us a batch of codes ahead of time, A or B will be more robust for both of us — a slow or failed call on your side becomes a customer not getting their discount. Choose C when codes are minted per user and there is no batch to share.
These sound similar and are not. Both are HTTPS and JSON; the difference is which way the call travels, and that decides everything about what your team owns.
Model B · one API call
You → Brizz
You are the client
You POST your list of codes to Brizz once, ahead of time, to hand over the batch you have already minted. It is the same kind of call your code makes to any third-party API. Nothing is hosted, nothing stays running, and nobody is waiting on it — if it fails you retry it tomorrow. Most partners do this from the dashboard as a CSV instead and never write the call at all.
Runs: once per batch · Owned: nothing after it returns
Model C · an HTTPS endpoint
Brizz → You
You are the server
You host a URL that Brizz calls, and you keep hosting it for as long as the campaign runs. It fires on every checkout where one of your codes is entered, with a customer waiting on the answer, so it has to be online, authenticated, and fast — the default timeout is 1500 ms. Your uptime becomes part of the customer's experience.
Runs: every checkout, live · Owned: hosting, auth, uptime, latency
Model A needs neither. Brizz mints the codes, so there is no batch to hand over and nothing to verify — the API on Model A's page is there only if you would rather trigger minting from your own code than from the dashboard.
Every flow in this guide is drawn the same way, so you can compare the models directly. Three lanes — Partner (you), Brizz, End User — and one vertical divider separating what happens ahead of time from what happens while a customer is at checkout.
Status and verification calls carry the code and Brizz identifiers only — never buyer identity, email or PII.
Any failure means no discount and a normal, full-price checkout. A sale is never blocked by a coupon problem.
A rejected code shows one generic message, so checkout can't be used to enumerate which codes exist.
A discount can never take a basket to zero. Brizz always leaves a genuine payable amount.
The cap, per-user limits and event scope are applied on our side, under a lock. You never track spend.
API keys are stored as keyed hashes; verification secrets are encrypted. A minted secret is revealed exactly once.
Tell us which model fits and we'll take it from there. For Model C, send your verification URL and preferred code prefix — we'll exchange credentials, run Test connection against your endpoint, and enable the campaign once it passes.
Brizz uses cookies to improve your experience and measure site usage. You can manage your preferences at any time.