Boberdoo delivers a won lead as an HTTP request to a URL you nominate. Point that URL at your VICIfast box and the record lands in a VICIdial list, DNC-checked, ready for the hopper on its next pass. Boberdoo builds deliveries in GET, POST, XML, SOAP or JSON, so the shape is yours to specify.
Integrations on demand. There is no Boberdoo connector to switch on, and we are not a Boberdoo partner. Our team wires your account to your server as a scoped piece of work, quoted per setup, because the field mapping and the rejection handling differ for every buyer.
Ping and post are not the same delivery
Most of the trouble on this integration comes from treating them as one thing.
The ping is a bid request. Boberdoo describes a lead - state, vertical, sometimes a hashed identifier - and asks what you will pay. Deliberately no PII. Nothing dialable changes hands.
The post is the record itself, sent only to whoever won the ping.
Only the post should ever reach add_lead. Wire a ping to your dialer and you fill a list with records you never bought and cannot legally call.
How the post reaches VICIdial
The delivery targets VICIdial's non-agent API:
https://your-box/vicidial/non_agent_api.php
?source=boberdoo
&user=<api-user>&pass=<api-pass>
&function=add_lead
&phone_number=5551234567
&phone_code=1
&list_id=<list>
&first_name=&last_name=&address1=&city=&state=&postal_code=&email=
&vendor_lead_code=<boberdoo lead id>
&dnc_check=Y&campaign_dnc_check=Y
Three fields carry the weight:
vendor_lead_code holds Boberdoo's own lead ID. Without it you cannot reconcile a disposition back to what you were invoiced for, and every billing dispute becomes a manual search.
list_id is the routing decision. One list per source, or per vertical, or per buyer campaign - whatever you intend to report on later. Changing your mind after a month of data is painful.
dnc_check=Y scrubs on arrival rather than at dial time. A record that should never have been bought never enters the hopper.
The response Boberdoo needs back
Boberdoo expects your endpoint to answer, and treats the answer as the accept or reject. non_agent_api.php returns its own success or error string, which is not the shape Boberdoo's spec asks for.
That gap is the integration. A thin endpoint sits in front, translates the post into the add_lead call, and returns the acknowledgement in the format your Boberdoo spec defines. It is also the right place to reject a malformed record before it reaches the dialer at all.
It also runs the other way
Everything above is traffic arriving. The dialer can call Boberdoo as well: VICIdial fires their API mid-call with the lead substituted into the URL, and the caller is transferred live if Boberdoo accepts. Boberdoo already returns a dynamic DID on the bid for exactly this, so the accept carries the destination with it.
A transfer accepted during the conversation is worth considerably more than a record posted after it, and it is a separate piece of work from the inbound path. See live transfer on a buyer API response for the hooks and the failure modes.
Gotchas
The buyer writes the spec, not the seller. Boberdoo's own documentation is clear that ping-post specs are supplied by the buyer. That is you. If nobody on your side has written one, the integration cannot start, and the first meeting is about agreeing fields rather than plumbing.
Duplicate posts happen. Retries, double-fires and re-sends are normal. Deduplicate on vendor_lead_code before calling add_lead, or the same person is called twice by two agents.
Phone formatting. VICIdial wants phone_number and phone_code separately. A post carrying +1 or hyphens in one field produces a lead the dialer silently never calls.
Timezone from the record, not the server. VICIdial derives call-time windows from the lead's postal code. A post missing postal_code inherits a default and can be dialled outside permitted hours.
Live calls, not just web leads. Boberdoo's ping-post also handles calls, with buyers returning a dynamic DID on the bid. If that is your model, the call-routing mechanism applies instead - see pay-per-call routing.