Question
How does CallerID.com hand caller ID to a POS or CRM system, which device should I pick, and can you help our software vendor build the integration?
Short answer
Every current CallerID.com device emits the exact same plain-text caller ID record, byte for byte. What changes between models is only how that record leaves the unit — over Ethernet (a UDP broadcast on port 3520), over a serial RS-232 COM port, or pulled from VoIP/SIP by our Vertex unit. There is no API, no keys, no polling, and no proprietary SDK: a downstream listener just reads the fixed-width fields straight out of the record.
The current device family
| Model | Lines | Phone connection | Data output | Captures |
|---|---|---|---|---|
| Whozz Calling? Basic — Ethernet Link (EL) | 2, 4, or 8 | Analog, parallel tap (Line Duplicator) | Ethernet RJ-45 — UDP/3520 broadcast | Inbound Caller ID |
| Whozz Calling? Basic — Serial | 2, 4, or 8 | Analog, parallel tap (Line Duplicator) | Serial DB9 RS-232 to a COM port | Inbound Caller ID |
| Whozz Calling? Deluxe | 2, 4, or 8 | Analog, in-line (signal passes through the unit) | Ethernet (UDP/3520) or DB9 RS-232 — same record | Inbound and outbound calls + call duration (full call accounting) |
| Vertex VoIP Caller ID | Sized to the site's SIP setup | VoIP / SIP — network bridge (no analog line needed) | Ethernet management port (UDP) — optional serial out | Caller ID pulled from VoIP/SIP traffic |
Pick the model to match how the store's phone lines arrive (analog vs VoIP/SIP) and how the software prefers to read the data (Ethernet vs serial). VoIP sites usually want Vertex; analog sites use Basic or Deluxe (Deluxe adds outbound calls + duration).
How a downstream system consumes it
- Open the data source. For an Ethernet unit, open a UDP listener on port 3520 (no handshake). For a serial unit, open the COM port at its configured baud rate. Parsing is identical from here — it's the same record either way.
- Locate the caller ID stream. Do not "find the first
$and read from there" — the compressed unit/serial header can contain a stray$. Instead, skip the fixed-length header and start reading at the 21st character of the payload. - Parse the fixed-width fields (line, I/O, S/E, duration, checksum, ring info, date, time, AM/PM, phone number, 15-char name).
- Look up the number in your database and screen-pop the customer.
The Ethernet packet shape is ^^ <unit_number> <serial_number> $ < ASCII data stream >, one UDP packet per call event. Three drop-in ASCII formats are available — Standard (MM/DD), Detailed (leading $, 4-digit year, optional checksum), and Call Accounting (MM/DD/YYYY + HH:MM:SS).
We co-develop the integration — royalty-free
When a customer's POS/CRM vendor needs to build or enable caller ID support, we help directly. We provide our Ethernet Link Supplement (programmer's reference: full packet format, the setup/command language, IP/MAC/port configuration, and royalty-free sample parser source code they can reuse), a sample UDP/3520 packet capture for testing a listener before any unit is on site, and we will co-develop the integration with the vendor at no licensing cost. Many systems already support our delivery natively — for example, Domino's Pulse reads our record over both a serial COM port and UDP port 3520, so "compatibility" there is largely enabling the existing caller ID feature and pointing it at our unit.