Route every call to the buyer who wants it — and see exactly why.
A workspace of your own: tracking numbers, the buyers you sell to, a routing plan with failover and real-time bidding in both directions. Every call keeps the record of every decision that was made about it.
You are billed for connected minutes and the rent on your numbers — never for a ping.
Call CA-482137
Home services — Texas · Northwind Media
Call received
+1 415 555 0142 called +1 888 555 0100, a tracking number on Home services — Texas, from Northwind Media.
Checks passed
The call passed every check before routing: the subscription is active, the wallet has funds, the campaign is live, the caller is not blocked, the campaign is open and the campaign is under its caps.
Asked buyers to bid
Asked 2 bidding endpoints for a price (412 ms): 1 bid and 1 declined.
Routing plan
4 targets were considered, in priority order: 2 could take the call and 2 were skipped. First in line: Acme Health — East.
Acme Health — West skipped
The target has reached its daily cap.
BlueSky Legal — Overflow skipped
The buyer is paused.
Attempt 1 · Acme Health — East
Rang Acme Health — East on +1 214 555 0118 — nobody answered after 22 seconds (SIP 480, the line was unavailable).
Attempt 2 · BlueSky Legal — Main
Rang BlueSky Legal — Main on +1 512 555 0133 — answered.
Connected
The buyer's leg answered, so the call is connected and the clock starts.
Call ended
The caller hung up after 4m 12s.
Converted
The buyer's leg talked past the target's duration threshold, so revenue and payout were recorded on the call.
A call’s waterfall, as the console prints it. The real one also names the cap that was hit, the price each target quoted and what the call earned.
How it works
Four steps from signing up to a routed call
Numbers, then the buyers you sell to, then the order you want them tried in. Nothing else has to be true before the first call arrives.
Buy tracking numbers
Search the carrier by area code or pattern and buy local, toll-free or mobile numbers from inside the console. Point each one at a campaign, at a publisher or at a pool that swaps numbers per visitor.
Add your buyers and their targets
A buyer is a company you sell calls to. A target is one way to reach them — a phone number, a SIP address or a bidding endpoint you ping for a price before the call. Caps, hours and states sit on both.
Build the routing plan
Attach targets to the campaign and order them: strict priority, weighted inside each priority tier or highest bid first. Set the failover budget and what a caller hears if nobody takes them.
Set it live
Every call that lands on one of your numbers is routed, recorded, priced and explained. Simulate one first if you like — the simulator returns the waterfall a real call would take, without a real caller.
Each step has a guide. Read the quickstart.
What is different here
The seven things this platform does on purpose
Each of these is a rule the code follows on every call, not a setting you have to find.
Every call explains itself
Each call keeps a decision waterfall: every check it passed, every target considered with the reason it was skipped and every dial attempt with the carrier's answer written out in words. "Why did this call not route?" is answered on the call, not by support.
Every ping is on the record
Pings in from your publishers and pings out to your buyers are both ledger rows, with the request, the response, the latency and the reject code. A no-bid is a row you can read, not a silence.
Bidding in both directions, billed on minutes
Publishers bid for your calls and you ping your buyers for a price on the same call. Real-time bidding is included on call tracking plans that include it, and a ping is never billed — whichever way it goes and whatever it answers.
Nothing fails silently
Webhooks and conversion pixels keep a delivery log. A failed delivery is retried on a fixed backoff, and after the last attempt it sits in the log waiting for you to replay it — rather than disappearing.
Everything is logged
Every configuration change — a publisher, a key, a ping URL, a target, a cap, a number, a webhook, an API key — writes an activity row with who did it and the before and after values. The log cannot be edited, by you or by us.
Drop-in compatible
Each publisher lane can switch on a single-step ping URL that takes Ringba-style parameters and answers in Ringba's field names, so a publisher repoints one URL. On the buying side, bidding targets ship with response presets for Ringba, Retreaver and TrackDrive.
Tags carry their provenance
Every tag records where it came from: the visitor's own page, the number, the publisher's ping, the platform or your API. Nothing a web page puts in a query string can overwrite a fact read off the call itself.
Who it is for
Anybody with calls on one side and buyers on the other
The same workspace, arranged differently depending on which side of the trade you sit.
Publishers
You generate the calls and sell them on. Take a number per campaign, or ping for a bid and claim it. Your own portal shows the calls you sent, the pings you made and whether each one paid.
Networks and brokers
You sit between supply and demand. Publishers on one side with their own lanes, payout terms and keys; buyers on the other with caps, hours and bidding endpoints. The margin on each call is recorded for you.
Buyers who also resell
You keep the calls that fit and pass the rest on. A routing plan sends a call down your own floor first and out to another buyer after it, with failover between them.
Agencies already on buy3
A workspace is its own account beside your agency, on a plan of its own. Some agency plans carry the tracking console as well — the plan row says so on the pricing page.
Capability by capability
What the platform does, and where in the console you see it. Every row is something built — there is no column here for what somebody else's product might do.
| Capability | How it works | Where |
|---|---|---|
| Real-time bidding, in and out | Publishers ping you for a bid and claim it; you ping your buyers' bidding endpoints for a price on the same call. Pings are never billed in either direction. | Included on plans that include it |
| The decision waterfall | Gates, targets considered, skip reasons, dial attempts and the SIP result in plain language — written as the call happens, never reconstructed afterwards. | Every call, on the call log |
| Drop-in ping URL | One single-step URL per publisher lane, taking Ringba-style parameters and answering in Ringba's field names. It cannot be switched on for a key that requires signed requests, because the URL is the credential. | Campaign › Publishers |
| Buyer response presets | A bidding target ships with presets for Ringba, Retreaver and TrackDrive, which fill in where the bid, the destination and the reject reason live in the reply. | Targets |
| Failover between targets | A target that does not answer, is busy or rejects the call releases its slot and the next entry in the plan is dialled — inside the failover budget you set on the campaign. | Routing plans |
| When nobody takes the call | Choose per campaign: hang up, speak a message or forward the caller to a fallback number. The call is logged with the reason either way. | Campaign settings |
| Number pools and dynamic insertion | A pool leases one number to one visitor and keeps the parameters their URL carried, so the call that arrives later is still attributed to the click. | Number pools |
| Tag provenance | Every tag is stored with its source — the visitor's page, the number, the publisher's ping, the platform or your API — so a filter can tell a claim from an observation. | Filters and tags |
| Webhooks and conversion pixels | Signed deliveries to your server, or a pixel URL filled from the call's own values. Both keep a delivery log with automatic retries and a manual replay. | On plans that include them |
| REST API | Scoped keys with a per-key rate limit and an IP allowlist. Every request a key makes is logged, refusals included, and each scope's description says exactly what it opens. | On plans that include it |
| Publisher portal logins | Your publishers sign in and read their own calls, their own pings and their own activity. Never your buyers, your destinations, the bids or the margin. | On plans that include it |
| Call recording | Recording is a switch per campaign. Recordings play in the console and are reachable through the API with the right scope. | Campaign settings |
| Activity log | Every configuration change with the actor, the object it was about and the values before and after. Rows are append-only — the database itself refuses an edit. | Activity log |
| Books, not custody | Revenue from the buyer and payout to the publisher are recorded on each call so your reports are right. Your buyers pay you directly and we hold none of it. | Every tracking call |
What each plan includes, and what it costs, is on the pricing page.
For developers
Every screen has an endpoint behind it
The console and the public API run the same handlers, so what your integration reads is what the console shows — the same fields, the same filters, the same errors.
- Keys are scoped: each scope's description says exactly what it opens, and nothing more.
- Per-key rate limits and an optional IP allowlist, with the limit returned in response headers.
- Every request a key makes is logged, refusals included, and readable on the key.
- Money is integer cents, every list is paged the same way and a machine-readable code is always the top-level code field.
- Webhooks are signed, retried on a fixed backoff and replayable by hand from the delivery log.
curl -s "https://api.buy3.io/api/v1/calls?outcome=converted&pageSize=2" \
-H "Authorization: Bearer $BUY3_API_KEY"Answers a paged list, each call with its campaign, publisher, buyer, target, talk time, recorded revenue, payout and tags. Calls in the API reference.
Pricing
Pay for the plan, the minutes and the numbers
Nothing per ping, nothing for a call no buyer answered and nothing taken out of what your buyers pay you.
Call tracking plans are not on sale right now
There is no call tracking plan on the public price list at the moment. Tell us what you route and we will set you up.
Questions
The questions people ask before they switch
What does "books only" mean?
It means we keep the record and not the money. On every tracking call buy3 stores what the buyer owes you and what you owe the publisher, so your reports, your margin and your exports are right — and no wallet moves. Your buyers pay you directly, you pay your publishers directly and the only money that leaves your workspace wallet is what the platform charges you: connected minutes and the rent on your numbers.
Do you charge per ping?
No. Real-time bidding is included on call tracking plans that include it and a ping is never billed — not one a publisher sends you, not one you send a buyer, whatever either of them answers. The platform's charge is per started minute of connected talk time, so a call no buyer answers costs nothing.
Can I bring publishers who already ping another platform?
Yes. Each publisher's lane on a campaign can switch on a single-step ping URL that takes Ringba-style parameters and answers in Ringba's field names, so the publisher repoints one URL instead of building a new integration. The two-step ping and post protocol is there as well for publishers that use it. The single-step URL cannot be combined with a key that requires signed requests, because the URL itself is the credential.
How does failover work?
The routing plan is an ordered list, and the call walks it. When a target does not answer, is busy or rejects the call, the slot it was holding is released, the next entry is dialled and the attempt is written to the waterfall with the carrier's reason. The campaign carries a failover budget, so the whole ring tree finishes inside a time you set. If the plan runs out, the campaign decides what the caller hears: a hang-up, a message or a forward to your fallback number.
What is logged?
Three separate records. The call keeps its waterfall — the gates, every target considered, every dial attempt and the result. The ping ledger keeps every ping in and out with its request, response, latency and reject code. The activity log keeps every configuration change with the actor and the before and after values, and nothing can edit a row once it is written — the database refuses it. Calls, reports, pings and activity all export as CSV.
Can publishers see their own pings?
Yes, and only their own. A publisher signs in to the publisher portal and reads the calls they sent, the pings they made and their own activity, with a version of each call's waterfall built for them. It never carries your buyers' names, a destination, a bid or your margin — those are your customer list and your price book.
How do number pools work?
A pool is a set of tracking numbers plus a public key that the JavaScript snippet on your site uses. When a visitor lands, the snippet leases them one number from the pool and swaps it into the page; the lease keeps the parameters their URL carried. When that visitor calls, the number identifies the session, and the click's parameters arrive on the call as tags with source "dni".
Is there an API?
Yes — a REST API on plans that include API access. A key reads calls, campaigns, targets, buyers, publishers, numbers, reports and pings. It can also report conversions, tag calls, replace a routing plan, change a target's price and caps, pause and resume, reset cap counters and manage the blocklist. Creating campaigns, buyers, targets and numbers stays in the console, and so does re-pointing where a target's calls go. Every key is scoped, rate-limited on its own and logged request by request.
More in the documentation and on the general FAQ.
Open a call tracking workspace
Buy a number, add a buyer, put them in a plan. You can route your first call today, and read exactly why it went where it went.