Your data lives in its own database.
Not a shared table with an account column on it. Alongside that: enforced 2FA, role-based access, signed postbacks, masked credentials, and an audit trail that remembers what you don’t.
Isolation you can point at, not a promise
Most platforms keep every customer in the same tables and separate you with a column and a WHERE clause. One missing filter in one query is all it takes. Datahubb gives each account its own database, so there is no shared table to query wrongly in the first place.
- A PostgreSQL database created for your account alone
- Requests resolve your tenant from the domain, then connect to your database
- Service connections reach your database through a proxy that validates a signed token
Who can do what, enforced where it counts
The interface is not the security boundary. The server is.
Two-factor authentication
TOTP with authenticator apps and recovery codes. An admin can require it across the whole account, not just switch it on for themselves.
Roles and permissions
Admin, buyer, and traffic-source roles out of the box, plus custom roles built from granular permissions. Buyers and sources see their own data and nothing else.
Scoped API keys
Lead submission runs on per-client keys, shown once when generated and regenerable at any time. A key is bound to the client it was issued to.
Secrets stay secret
Provider tokens and API credentials are masked in the interface and redacted from usage and request logs, so a support session cannot leak one by accident.
The server is the gate
Role restrictions are enforced at every endpoint, not in the interface. A stale frontend or a hand-crafted request does not get further than a correct one would.
Token-based support access
When we help you, it runs through an explicit, time-limited token rather than a shared password. Nobody needs your credentials to do their job.
Your partners can prove it was really you
An outbound postback is a request arriving at somebody else’s server claiming to be from you. Sign it, and they can verify that claim — over the method, the URL, and the body, so a tampered payload fails the check.
- HMAC-SHA256, with the algorithm and version sent as headers
- Custom domains get their certificate provisioned automatically
- Credentials are redacted from logs, so a support session cannot leak one
Tools for your obligations, not a promise about them
Datahubb does not make you compliant — nothing does. It gives you the gates, the checks, and the records to run a compliant operation, and it is honest about where that line is.
DNC and blacklist scrubbing
Federal and state DNC, wireless, and suppression lists run as a hard gate on US phone numbers. A lead that fails is rejected at ingest, before anyone can sell it.
Litigator checks
Known TCPA litigators and blacklist flags surface at validation, so you can turn them into reject rules before a lead is ever routed to a buyer.
Consent captured with the lead
The consent language and its timestamp travel with the lead, alongside the IP address and page URL it was submitted with — so the record of how consent was collected stays attached to the lead it was collected for.
One-to-one consent bidding
Flag a lead as consented and the ping returns named buyer bids. The source picks the brands the consumer actually agreed to, and only those buyers receive the lead.
When a payout changed and nobody remembers doing it
Changes to the entities that matter — campaigns, buyers, suppliers, integrations, filters — are recorded with the person who made them, where they made them from, and what the value was before they touched it. Not so you can blame somebody, but so you can find out what happened in under a minute.
- Who made the change, and from which IP address
- What changed — the old value and the new one
- When it happened, down to the entity and the record
Every change, attributable
Frequently asked questions
Ask us the hard questions.
Send your security questionnaire, or start a 14-day trial and look at it yourself.