Real-time bidding
Real-time bidding is how a call opportunity gets priced and placed before the caller is connected. A publisher pings a buyer with what they know about the call; the buyer answers with a bid and a phone number; the publisher dials that number. The whole exchange happens in the seconds between the caller pressing dial and hearing a ring.
The two directions
Section titled “The two directions”Moja names RTB from the perspective of the traffic, not the account, which trips people up on first read:
| Name in Moja | You are | What happens |
|---|---|---|
| Inbound RTB | the buyer | A publisher’s RTB request arrives at your campaign. Your campaign bids, and the winning bid returns one of your numbers. |
| Outbound RTB | the seller | Moja sends your call opportunity out to other buyers’ endpoints, collects their bids, and routes the call to the winner. |
Lifecycle
Section titled “Lifecycle”sequenceDiagram
participant C as Caller
participant P as Publisher
participant M as Moja (buyer campaign)
participant B as Target / buyer
C->>P: Calls the publisher's number
P->>M: RTB request (caller data, agreed metadata)
M->>M: Apply filters, caps, hours, duplicate rules
M-->>P: Bid amount + phone number, valid until expiry
P->>M: Dials the returned number
M->>B: Bridges the call to the target
B-->>M: Answer, duration
M-->>P: Conversion and payout per the agreed rule
Two things in that diagram cause most integration problems. The returned number is bid-specific and time-limited — dialling a cached number from an earlier bid is the usual reason RTB logs exist without matching call logs. And the filters step is where a no-bid comes from: caps, hours, a failed filter, or a parameter the campaign required and did not receive.
Guides
Section titled “Guides”If you are the publisher
Section titled “If you are the publisher”Start with How publishers send RTB requests to a Moja buyer — request format, required parameters, and the response contract — then Getting started as a publisher for the end-to-end path.

