Skip to content
Newv6.18.0Generated values for buyer deliveries, a safer Google Sheet connection, and a post log filter step that explains itself.Read the changelog
Partner portals

Your partners log in and see only what’s theirs.

Buyers, suppliers, and traffic sources each get a workspace scoped to their own row — their leads, their volume, their payouts. Not your margin, not your buyers, not each other. The server enforces it, so the scope holds even when the interface doesn’t.

Start Free Trial
Book a Demo
A login per role
Out-of-scope rows return 403
Self-serve, not admin-serve
Role-based portal view for buyers, suppliers and traffic sources
Who logs in

Three roles, three very different views

Every partner arrives at a workspace built around the one thing they came to do — and stops there.

A buyer sees what they bought

The leads they purchased, their bids, and a live view of their own caps — day, week, month, lifetime, used against limit — read from the same service the distribution engine enforces with. What they see is what is actually being enforced, so a “why did you stop sending?” email answers itself.

A supplier gets its own integration

API key and supplier id in one place, API docs generated from your real campaign fields, and a synchronous response on every post — accepted, rejected, duplicated, with the payout attached. No spreadsheet of field names emailed back and forth.

A traffic source runs its own tracking

Affiliates author their own postbacks instead of queueing behind you for a hand-crafted URL, and can point their own Meta pixel at the platform with the built-in CAPI preset — their credentials, their events, their conversions.

And none of them see your margin

Revenue and profit tokens, and the entire buyer namespace, are stripped from the autocomplete, locked in the editor, and rejected at save. Buyer names come back as “#42”. A partner can measure their own performance without ever learning what you sell their leads for.

Invite them, don’t onboard them

Send an invitation with an email and a role. They set their own password, and the account comes up already scoped to that role. Nobody is sharing a login, and nobody is waiting on you to provision anything.

Roles you define, not roles you inherit

Admin, buyer, and traffic source ship as defaults, and you can build custom roles from granular permissions when the defaults are the wrong shape. Two-factor can be required across every user in the workspace.

Role-scoped access

Hiding the menu is not access control

Plenty of partner portals scope by omission: the link isn’t rendered, so the data must be safe. It isn’t. Datahubb scopes on the server — the list is filtered to your own records before it is built, an access check runs on every read and every write, and a record you don’t own comes back 403 whether the request came from the app or from curl.

  • Lists forced to the caller’s own records, whatever the request asks for
  • Out-of-scope rows return 403 on read and on write alike
  • On create, the owner is forced to the caller — spoofed payloads get remapped
  • Admin-only tokens like revenue and profit are rejected at save, not blanked
Signed in astraffic source
GET
/postbacks
their own configs
200
GET
/postbacks/24
a partner’s config
403
GET
/buyer/7/cap-status
a buyer they don’t own
403
PUT
/postbacks/18
adds {{event.revenue}}
rejected
scope forced server-side → every read, every write
Self-serve

Work your partners do without opening a ticket

Every one of these was an email to you at some point. That is the whole return on a portal.

A buyer checks their own live cap usage before asking you why volume dropped
A buyer manages their own bids and their own buyer-level filters
A supplier copies its API key and supplier id, and reads docs generated from your real fields
A traffic source authors its own postback configs, scoped to the campaigns you assigned it
An affiliate wires up its own Meta CAPI pixel — credentials, event, user data, triggers
Every partner watches their own volume and their own payouts, without a shared login
Admin-only

And what never crosses the wall

Self-serve is only worth having if the boundary is real. Here is exactly where it sits.

Your margin, and every route to it

A traffic source’s postbacks are locked to payout. Revenue and profit are admin-only tokens, refused at save rather than quietly emptied — and the gate runs both ways, so they cannot strip an admin-set token either.

Who your buyers actually are

Buyer scopes are hidden from partner-facing editors and buyer company names are never looked up for them — they render as an id. The demand side of your business stays yours.

Everybody else’s rows

A partner’s list is filtered to their own records by the server, whatever the request asks for. Another partner’s record is a 403, not an empty state you have to trust.

Pricing, routing, and the guest list

Buyer prices, supplier payouts, campaign routing, filters, roles, and who gets invited in the first place stay on your side of the wall. Self-serve is a set of doors you open, one at a time.

FAQ

Frequently asked questions

See the leads they bought, manage their bids, and read their own cap usage live — leads and budget, for the day, week, month, and lifetime, each shown as used against limit. Those numbers come from the same service the distribution engine uses to enforce the caps, so the portal is not a friendly approximation of the truth. They can also manage their own buyer-level filters. Ask for a buyer they do not own and the request comes back 403.

Their own integration and their own numbers: API key and supplier id, API docs generated from your actual campaign fields, what they posted, and the payout attached to it. Every lead they post gets a synchronous response — accepted, rejected, duplicated, with the payout — so they know where they stand without asking. Postbacks, by design, go to traffic sources rather than suppliers; a supplier’s feedback is the response to its own post.

No, and not by convention — by refusal. The revenue and profit tokens and the whole buyer namespace are filtered out of their autocomplete, locked in the editor’s row-level controls, and rejected at save with an explicit “contact an admin”. Buyer names are never resolved for them; they see an id. On the Meta CAPI preset, the value they can send is locked to their own payout. Your margin is not hidden from them — it is unavailable to them.

No. A traffic source’s list is forced server-side to the records whose recipient is their own client id, regardless of what the request asks for, and an out-of-scope row returns 403 on read and on write alike. Their campaign picker only offers the campaigns you assigned them. One affiliate cannot enumerate another affiliate, let alone their volume.

The server, which is the only answer worth anything. An access assertion runs on every read and every write; on create, the recipient is forced to the caller’s own id, so a spoofed payload is silently remapped rather than honoured. A stale frontend or a hand-rolled API call gets the same treatment as the UI. And each customer’s workspace is a separate database, so there is no shared table for a scoping bug to leak across — security covers how that is built.

They answer different questions. White-label is what the product looks like — your logo, your palette, your domain, loaded before the login page even renders. Portals are what a partner can do once they are through that door, and what the server will not let them do. You want both, but the one that keeps your margin private is this one.

You invite them by email with a role attached. They follow the link, set their own password, and arrive already scoped — no shared credentials, no provisioning ticket. Beyond the default admin, buyer, and traffic-source roles you can compose custom roles from granular permissions, and two-factor authentication can be required for every user in the workspace.

Give your partners a door, not a database.

Start your 14-day trial. Full platform access. Card required, no charge if you cancel during the trial.

Start Free Trial
Book a Demo