RB2B API Review 2026: Features, Setup and Limitations

Key takeaways:

• RB2B’s documented API is an OEM partner API, not a general customer API. It exposes four endpoints: add a domain, remove a domain, list active domains, and check credit usage.
• There is no endpoint to query identified visitors. Data leaves RB2B through a webhook that pushes every page view from your tracked domains in real time.
• RB2B does not support HMAC signature verification on outgoing webhooks, and its own recommended workaround is to treat the destination URL as a shared secret.
• Enrolling in the OEM program deactivates your consumer RB2B account. An account is one or the other, never both.

If you came here expecting a REST API that returns the people who visited your website, this review has bad news and a useful explanation.

The RB2B API documentation that exists publicly covers the OEM partner program, which is built for companies embedding RB2B’s identification technology into their own platform. It manages which domains are tracked and reports credit usage. It does not let you query visitors.

The actual data path is a webhook, and understanding that distinction is most of what a developer needs before planning an integration. This review covers both surfaces, the constraints attached to each, and what the pricing looks like on either side of the OEM line. Our own product sits downstream of tools like this one, and our integrations page lists where that handoff usually lands.

What the RB2B API Actually Is

RB2B identifies people who visit your website, resolving anonymous traffic to individuals rather than just to companies. That capability is the product, and the RB2B API is a thin control plane around it rather than a way to reach the data.

The RB2B API is aimed at companies and agencies who want to embed RB2B’s website visitor identification directly into their own platforms or white-labeled solutions, which the OEM program exists to support. Through the API and webhook system, partners manage domains and receive live data into their systems.

That framing explains the endpoint list, which is short by design.

Notice what is missing. There is no GET /visitors, no search, no filter by date range, and no way to pull yesterday’s identifications. The API tells RB2B where to look and tells you what you have spent. Everything else arrives by webhook.

That is a genuinely different shape from most tools in the wider lead generation API category, where the normal contract is a request-response lookup you control. Here the vendor controls the timing and you control only the destination, which inverts who has to handle backpressure, retries and storage.

The Webhook Is the Real Integration

The RB2B API plays no part in moving the data itself. Once you set a webhook URL, RB2B begins sending every page view from your added domains to that endpoint in real time, as visitor de-anonymization and pageviews occur.

This is a firehose rather than a query interface, and it shapes the architecture on your side. You need an endpoint that can absorb continuous traffic, deduplicate people across page views, store what you receive, and decide what matters. RB2B does not hold that state for you to query later.

By default the OEM script identifies both contact-level and company-level visitors. If you only want person-level records, company-level collection can be switched off in the dashboard, which is worth doing before you start receiving traffic rather than filtering afterward.

The Webhook Security Problem

This deserves its own section because it is the most consequential technical fact in the integration, and RB2B documents it plainly rather than hiding it.

RB2B does not currently support signature verification, such as HMAC, on outgoing webhook payloads. There is no cryptographic way to confirm that an incoming request genuinely came from RB2B.

Its recommended approach is to treat the webhook URL itself as a shared secret: generate a long random token and include it as a path segment, for example https://your-app.com/webhooks/rb2b/<random-token>, rather than as a query parameter. RB2B’s stated reasoning is that a secret placed in the query string is far more likely to be captured somewhere it should not be, whether by a proxy, a log file or a referrer header.

That advice is sound and RB2B is right to give it. It is also, as the company acknowledges, not a full substitute for a signature, because it provides no payload-level integrity checking. Anyone who learns the URL can post to it, and you cannot tell a forged payload from a real one.

The practical implications are worth stating concretely. Treat inbound payloads as untrusted input, validate their shape before processing, rate-limit the endpoint, rotate the URL if it ever appears anywhere it should not, and avoid triggering irreversible actions such as outbound sends directly from a webhook payload without a verification step in between.

Most teams do not write that receiver themselves. RB2B publishes a setup guide for n8n, and routing the stream through an automation layer gives you somewhere obvious to put deduplication and qualification logic, much as we described when writing up n8n’s MCP support. The trade is another moving part between the visitor and the sequence, which is usually worth it here precisely because the payload cannot be verified.

What It Costs

RB2B has two commercial models, and the OEM line separates them absolutely.

Standard consumer plans are published and start at nothing, though the free tier is narrower than the marketing implies.

The free plan does not do the thing RB2B is known for. Person-level identification, LinkedIn URLs and business email addresses arrive progressively across the paid tiers, with emails appearing only at Pro. A seven-day Pro trial is offered.

OEM accounts are billed differently. Instead of a monthly credit pool, they use a cost-per-resolution structure reconciled once a month. RB2B states directly that custom pricing is not offered on the OEM program, that its plans and rates are fixed, and that if none of the available plans fit, the program may not be the right fit.

Cost per resolution is the honest way to price this, and it also removes your ceiling. A traffic spike becomes a bill rather than a throttle, so an OEM partner passing costs to end customers needs its own metering rather than relying on RB2B to cap anything. That is a familiar dynamic across intent data APIs, where consumption tracks attention rather than effort and the invoice follows whatever your marketing did that month.

How to Set It Up

Setup differs depending on which side of the OEM line you are on, and the consumer path is the one most readers need.

Standard Accounts

There is no API key to generate, because there is no query API to call. What you configure is the destination.

1. Add the RB2B script to your site so identification can begin.
2. Open the webhook settings in your dashboard and set your destination URL.
3. Decide whether you want company-level records alongside contact-level ones, and switch company-level collection off if you only want named individuals.
4. Confirm data is arriving before you build anything downstream, because there is no backfill if you miss it.

OEM Partner Accounts

OEM partners get the four-endpoint API on top of the webhook, and the key for it lives in the dashboard once you are enrolled.

1. Retrieve your OEM API key from the dashboard and store it server-side.
2. Send it in the request headers on every call to the domain-management endpoints.
3. Register each domain you intend to track with the add-domain endpoint, and confirm the list with the list-domains call.
4. Set your webhook destination, using a long random token as a path segment rather than a query parameter.
5. Poll the credit-usage endpoint on whatever schedule your billing needs, since consumption is reconciled monthly.

The ordering matters more here than in most integrations. Domains start producing page views the moment they are registered, so having the receiving endpoint live before you add the first domain avoids losing records you cannot request again.

Where the RB2B API Falls Short

The constraints here are unusually hard-edged, and most of them are commercial rather than technical.

The either/or account model is the biggest constraint by some distance, and it is the one most likely to derail a plan late. Joining the OEM program switches off your consumer account’s functionality, and a single account cannot hold both configurations. Running the OEM script and the consumer script on the same site or page is not supported and will cause tracking to fail. Teams that want both need two separate accounts.

There is no query API at all, which is the constraint that shapes every design decision downstream. If your system misses webhook deliveries during an outage, there is no documented endpoint to backfill from, so durability on your receiving endpoint matters more than it usually would. Queue the payloads on arrival and process them separately, rather than doing the work inline and risking a slow downstream call costing you a record you cannot request again.

Identification is also probabilistic rather than certain, which the resolution tiers imply without stating outright. Basic and premium resolution differ in how confidently a session is matched to a person, and no vendor in this category resolves every visitor. Building on the assumption that a named record is definitely that person, and acting on it in outbound copy, is how these tools produce their most embarrassing failures.

Webhooks are unsigned, as covered above, and that constraint propagates into every downstream system you feed, since none of them can verify the origin either.

Pricing is non-negotiable on the OEM side, which is unusual for a partner program and worth knowing before you invest in a business case built on volume discounts. Most OEM arrangements assume rates improve as a partner scales, and here they do not, so model your margin at the published rate rather than at a hoped-for one.

Coverage is US-centric, which is a practical constraint rather than a criticism. Person-level identification depends on the underlying identity graph, and those graphs are far denser in the United States than in Europe, where the regulatory position on this kind of processing is also markedly less settled.

There is also a compliance dimension that is not RB2B’s failing but is very much the buyer’s problem. Person-level identification of visitors who never filled in a form sits close to the line privacy regulators watch.

Under the California Consumer Privacy Act, residents have the right to know what personal information a business collects and the right to opt out of its sale or sharing. Businesses must honor a browser-level Global Privacy Control signal as a valid opt-out, and the statute’s thresholds reach businesses handling the personal information of 100,000 or more California residents or households.

None of that makes visitor identification unlawful, and RB2B operates openly in a large market. It does mean the compliance work belongs to you, in your privacy notice, your opt-out handling and your record of what you do with an identification you never asked the visitor for.

What the Data Actually Looks Like

Two identification levels arrive through the same stream, and the distinction drives everything you build on top.

Company-level records tell you an organization visited. They are the safer, lower-value signal, available even on the free plan, and they behave like classic reverse-IP lookup.

Contact-level records name an individual, which is RB2B’s differentiator and the reason it is discussed differently from older visitor tools. On paid tiers these carry a LinkedIn URL, and from the Pro plan a business email address.

The content format for each field is documented, and the OEM script collects both levels by default with company-level collection switchable in the dashboard. Deciding which levels you want before traffic starts flowing is easier than filtering a stream you are already storing.

The judgment call is what a single page view justifies. An identification is a weaker signal than a form fill, because the person never chose to tell you anything, and treating it as equivalent produces outreach that reads as surveillance.

Repeat visits to a commercial page mean something; a single blog view usually does not. Reading intent signals proportionately is the difference between outreach that lands and outreach that unsettles people.

Using RB2B With Reply.io

RB2B answers who was on your site. We answer what happens next. Neither of us does the other’s job, which makes the pairing simple to reason about.

The join between them is a webhook on our side too, which is the part worth designing deliberately. Our platform both receives and emits webhooks, so an RB2B identification can create a contact and start a sequence, while our own events push reply, bounce and status changes back out to whatever system you treat as the source of truth.

Resist the temptation to wire the firehose straight into a sequence. RB2B sends every page view, and someone who read your pricing page twice is not automatically someone to email.

Buffer the stream, deduplicate by person, apply whatever qualification rule you would use on any inbound lead, and only then create the contact. The unsigned-webhook issue is a second reason for that buffer, since it puts a validation step between an unverifiable payload and a message a prospect actually receives.

Our own gap is worth stating in the same breath: we hold no visitor identification of any kind and no way to resolve an anonymous session, so this is a genuine two-tool workflow rather than a feature we are pretending not to have. Anyone wiring that up themselves will find our API documents the contact and sequence endpoints it needs.

Who the RB2B API Is For

The OEM API suits software companies and agencies embedding visitor identification into a product they sell, which is exactly the audience it was built for. Within that scope it is well judged: four endpoints is the right number for managing domains, and the webhook does the rest.

Everyone else is served poorly, and that is worth being blunt about. If you are a standard RB2B customer wanting to pull your own visitor data programmatically, the OEM API is not for you, and enrolling to get it would deactivate the account you already use.

Teams comparing the category more broadly should look at what happens to the signal rather than at how it is captured, since that is where these tools actually differ. Our roundup of Leadfeeder alternatives covers the visitor-identification field, including the tools that stop at company level and cost considerably less.

Anyone evaluating the RB2B API specifically should start by confirming which side of the OEM line they are on, because that single answer determines whether the four endpoints are available at all. For most readers the honest conclusion is that the RB2B API is not the integration path; the webhook is, and it is available without changing account type.

Turning identified visitors into conversations? Start a free trial and wire the webhook into a real sequence.