A telephony API lets your systems create and read calls programmatically; webhooks let the telephony system tell you the moment something happens. For a sales team, the loop worth building is short: a signal fires in the CRM or on the website, a contact lands in a rep's dial session with the trigger attached, the call completes, and the disposition, recording and next step go back to the CRM without anyone typing. Here is how that loop works, the five automations that pay, the three mistakes that lose data silently, and how we expose it at Sonik.

API or webhook: which direction is the arrow

The distinction decides your architecture.

• The API is pulled by you. Your system asks: create this calling list, add this contact, start this session, give me yesterday's call stats. Synchronous, on demand, quota-limited.
• The webhook is pushed to you. The telephony system says: this call just ended, disposition "meeting booked", recording here. Asynchronous, event-driven, near real time.

The most common mistake is using the API for what the webhook is for: polling "has anything changed?" every minute. For a ten-rep team at 200 dials a day each, that is thousands of requests a day to detect two thousand events that a webhook would have delivered for free, with less latency. Rule: write with the API, listen with webhooks.

The five sales automations that pay for themselves

1. Signal to dial session

The highest-value one. A contact from a target account visits the pricing page at 9:40; by 10:15 they are in the right rep's session with "visited pricing page, 35 minutes ago" on screen. Trigger-based openers reach a 7-10% meeting rate in our analysis of 1,000,000 B2B cold calls in France, against 2-3% for pitch-first openers. The automation is what makes the trigger fresh. Same pattern for job changes, closed-lost anniversaries and dormant leads, which is where half of Sonik's own pipeline comes from.

2. Disposition to CRM

On every call.completed event, write disposition, duration, recording link, summary and the next task onto the existing CRM contact. Unanswered attempts increment a counter instead of creating an activity. This is the automation that removes an hour of typing per rep per day and makes the CRM trustworthy.

3. Meeting booked to the team

A meeting.booked event posts to the sales channel, creates the calendar hold, and notifies the AE with the recording. Thirty minutes of plumbing; it also does more for calling culture than most contests.

4. Enrich on entry

When a contact enters a calling list without a mobile number, call the enrichment provider (or a waterfall of two or three, which matters for European coverage) before the session starts. No mobile, no call, so this runs ahead of the rep, not during.

5. Stats to your reporting

A nightly pull of calls, connects and meetings by rep, persona and hour into the warehouse or the dashboard. Timing is where the gains hide: our data shows 15.8% connect at 4pm against 9.8% at 8am, and you only see your own version of that curve if the timestamps leave the telephony tool.

Code or no-code: where the line falls

Start no-code. A visual automation platform with the dialer's native trigger and the CRM's native action validates automations 2 and 3 in an afternoon. Move to code when one of three things happens: the per-task bill exceeds a developer day a month, the logic passes roughly fifteen conditional steps, or latency becomes a business problem because reps call people who booked ten minutes ago.

Automation 1 is the one that usually ends up in code, because it joins website, CRM and telephony data and needs deduplication and prioritisation rules. Automation 2 should be native in the dialer; if you are writing it yourself, ask why the vendor did not.

The three architecture pitfalls

1. Polling in a loop. Covered above. It burns quota, adds minutes of latency and still misses events between polls. Listen with webhooks; use the API to backfill.
2. Two systems owning one field. If the CRM workflow and the dialer both write "last contacted", whichever syncs last wins and nobody can reproduce the bug. Document one owner per field: the CRM owns lifecycle and owner; the dialer owns call outcome; enrichment owns phone and email.
3. No retries, no alerts. A webhook endpoint that returns a 500 at 11:02 loses that call forever unless the sender retries with backoff and you alert on final failure. Idempotency keys on your side, so a retried event does not log the call twice.

Securing the integration

• One API key per integration, named, so you can revoke the Slack bot without breaking the CRM sync.
• Secrets in a vault or environment, never in source or a shared doc. Rotate on a schedule and immediately when someone leaves.
• Verify webhook signatures. An unsigned endpoint will accept a forged meeting.booked from anyone who guesses the URL.
• Minimise payloads. Recordings and transcripts are personal data under GDPR; send a link with an expiry, not the audio, and honour consent.revoked events by stopping calls and purging where required.

How Sonik approaches the telephony API

Sonik exposes the loop above through an API and webhooks, alongside the native HubSpot and Salesforce integrations that most teams use without writing code. The shapes below are simplified for illustration; the principle is what matters.

Inbound, via the API: create or update a calling list from your own signal source, add a contact with the trigger text and persona attached, and schedule it into a rep's session for the best time slot. A minimal request carries the CRM contact id, the trigger ("pricing page visit, 35 min ago"), the persona and a priority.

Outbound, via webhooks: a call.completed event with contact id, disposition, duration, recording link, AI summary and the rep's next step; a meeting.booked event; attempt counters for unanswered dials. Events are signed and retried with backoff. Sonik never creates contacts in your CRM; it writes on the record you gave it.

The design rule is the same as our integrations: the CRM owns the contact, Sonik owns the call. Details on the signals page and the dialer page.

Conclusion

Use the API to write, webhooks to listen, and build the loop that turns a signal into a dial session and a disposition into a CRM record. Start with the meeting-booked alert and the disposition write-back in no-code, move signal-to-session into code when it earns it, and give every field one owner. This week, list the copy-paste steps between your website, CRM and dialer. Each one is an automation with a known payback.