Ping-Post

Ping-post gives your call vendors a way to ask "can you take this caller right now?" before they transfer. careCycle answers with a live yes or no and the number to send the caller to. Any caller details the vendor includes with the ping get saved, so when the call shows up a few seconds later, the customer record and the agent's screen are already filled in.

Every ping is logged against the source. That means you can finally see which vendors send the callers they say they will, and which ones ping a lot but never follow through.

The flow, start to finish:

1. The vendor pings careCycle with the caller's phone number and whatever qualification data they have, using an API key you give them.
2. careCycle checks real availability (live agents, business hours, AI coverage) and responds with the source's tracking number.
3. The vendor transfers the caller to that number. The arriving call links back to the ping automatically, so attribution, billing, and the pre-filled customer record all just work.

Vendors can still transfer without pinging. Those calls are answered and attributed by the tracking number like always. Pinging adds the availability check, the pre-filled records, and per-vendor conversion reporting on top.

Setting up a vendor

Managing vendor keys

Vendor keys are regular careCycle API keys with two restrictions built in:

• Permission: ping-post only. The key can't read or write anything else in your account. If it ever leaks, the worst it can do is check availability.
• Source scope: the key only works for the sources it's scoped to. Pinging any other source returns a 403.

Keys are organization credentials, not personal ones. They keep working when the employee who created them leaves your team, so vendor integrations survive staff changes. Revoking access is always per key, from Settings > Developer > API Keys.

You manage them from Settings > Developer > API Keys:

• Rotate by creating a new key scoped to the same source, handing it to the vendor, and deleting the old one once they've switched over.
• Revoke by deleting or disabling the key. The vendor loses access immediately and the source itself is untouched.
• Vendors with multiple traffic sources can share a single key scoped to several sources (or all of them), though separate keys keep revocation surgical if a relationship goes sideways.

Watching vendor performance

Source performance reporting includes a full ping funnel for every source, from the vendor's first ping all the way to the sale:

Conversions use cohort attribution: a conversion counts toward the ping that produced the caller, even if the sale closes after your report window ends. That keeps funnel percentages stable and comparable across vendors.

On the Sources performance page, sources with ping traffic get a Pings column. Click it to open the ping activity view: volume and accept-rate charts over time, plus a table of every individual ping with its answer, decline reason, qualification fields, whether the caller arrived, and whether the call went billable and converted. The same data is available through the API as List ping activity if you'd rather pull it into your own reporting.

How to read it:

• Low ping_to_call_rate means the vendor pings but doesn't send the caller. Often they're shopping the caller to several buyers at once and losing races, or pinging speculatively.
• A wide gap between dialed and billable means callers arrive but hang up before your billing threshold, a caller-quality signal worth raising with the vendor.
• A wide gap between billable and converted means you are paying for calls that do not become business: the traffic connects but does not buy. Compare pings_converted across vendors before renewing anyone's budget.
• Calls with no pings mean the vendor is transferring blind. They lose the customer pre-fill and risk dropping callers into closed hours.
• Lots of unavailable answers deserve a look at the reasons. no_agents_available during business hours is a staffing signal. after_hours means the vendor sends traffic outside your coverage window, which is a good argument for after-hours AI coverage on that campaign. no_licensed_agents means the vendor sends states your team isn't licensed for, which is a conversation about their targeting, your hiring, or both.

Ping sessions stay open for 30 minutes after we answer. Sessions that expire are your "pinged but never called" number.

Controlling who answers a vendor's calls

The availability answer is only as honest as the pool behind it, so the same controls that route real calls also shape ping answers:

• Per-agent source blocks. If an agent shouldn't take calls from a specific vendor, block that source for them, either from the campaign's routing settings or straight from the Air Status board on the dialer wallboard (each agent and campaign cell has a Sources menu). Blocked agents don't ring for that source's calls, and they don't count toward its ping availability. If the only agent on air is blocked from the source, its pings get no_agents_available.
• Air status. Agents taken off air for a campaign stop counting toward every source on it.
• State licensing. If the campaign's routing is set to only ring state-licensed agents, a ping that includes the caller's state only gets a yes when someone licensed in that state is actually available. Otherwise the vendor sees no_licensed_agents. The setting lives in the campaign's routing configuration, and agent licenses live on each member's profile. AI-answered numbers accept any state, since licensing is enforced when the AI hands the caller to a human.

Compliance built in

The ping flow is designed around the CMS rules for sharing beneficiary data between marketing organizations (42 CFR 422.2274):

• Consent attestation is required. Every ping must carry transfer_consent: true, the vendor's attestation that a permitted basis applies: the caller verbally agreed to the transfer (to an agent or an IVR prompt), the caller dialed the number themselves (ad click-to-call routed straight through), or written consent naming your agency is on file. Vendors record which basis via consent_basis, and it's stored on every session for audits. Pings without the attestation are rejected.
• Failed pings are scrubbed, unless consent says otherwise. When a ping never becomes a connected call, the caller's personal data (name, DOB, phone, qualification fields) is purged from the session after 72 hours: without a connection, there's no lawful basis to hold it, and the one thing you could do with it (call them back) is the exact move regulators flag. The exception is pings that carried written-consent evidence naming your agency (pewc_artifact or consent_basis: "pewc"): those callers consented to you having their data, so the sessions are retained as recoverable leads. Consent evidence and funnel metrics always survive the purge, and data from completed transfers stays with the call record it belongs to.
• Consent evidence rides along. Vendors can attach consent_timestamp, PEWC references, TrustedForm certificates, TrueCall IDs, Jornaya LeadiDs, and the transferring agent's NPN. Everything lands on the ping session where you can produce it in a plan or CMS audit.

The platform enforces the attestation and the data handling; the rest of TPMO oversight lives in your vendor agreements. Terms worth writing into them:

• Pings carry only data the caller provided themselves, backed by the consent captured where they gave it (form consent for web-originated traffic). No appended or purchased data.
• The licensed-agent transfer disclosure is delivered on the vendor's leg (agent script, or the IVR greeting on click-to-call routes), and recording disclosure on any leg they record.
• Consent evidence (consent_basis, TrustedForm certificates, PEWC references) is sent with every ping so your audit trail builds itself.

Your side of the call keeps the TPMO disclaimer and your own recording disclosure in the greeting flow.

None of this is legal advice. Have your compliance counsel review your vendor contracts and consent capture before turning on live traffic.

When a vendor reports a problem