SMS integrations for CRMs: Pipedrive, Salesforce, Airtable and more

Connecting texting to a CRM looks like a one-afternoon job. You install an app or wire up a connector, send a test text to your own phone, see it arrive and call it done. The trouble shows up weeks later. A contact gets the same reminder twice, someone who texted STOP gets a follow-up from a different tool, or a reply lands in the SMS inbox and never reaches the deal record your rep is working from.

This post compares the three ways to connect SMS to a CRM or workflow tool: native apps, Zapier-style connectors and direct API builds. It covers what each one costs you in setup and upkeep, and the sync problems that break each of them. We make Ready, so we'll also say plainly where our product fits and where it doesn't.

The three ways to connect texting to a CRM

Every CRM SMS setup reduces to one of three patterns.

Native app. A marketplace app built for one CRM, such as an AppExchange listing for Salesforce or a Pipedrive Marketplace app. You install it, authorize it, and texting shows up inside the CRM's own screens. The vendor owns the sync logic.

Connector. Zapier, Make or n8n sits in the middle. A CRM event ("deal moved to Proposal Sent") triggers a step that calls the SMS provider. A second flow carries inbound replies back. You own the flows, and the connector platform owns the plumbing.

API build. Your code, or the CRM's own automation engine, calls the SMS provider's REST API directly. Replies and status updates come back through webhooks to an endpoint you control. You own everything.

None of these is wrong. A five-person sales team on Pipedrive sending a few hundred texts a month is usually better off with a native app or a single connector flow than with a custom build. A software company texting on behalf of thousands of its own customers needs the API, because a connector can't handle per-customer numbers and registration.

Notes for specific tools

Pipedrive

Pipedrive's marketplace has several SMS apps, and its workflow automations can fire webhooks on plans that include them. That gives you a clean API pattern. A deal stage change fires a webhook to a small service you run, and that service sends the text. Ready's App Library can also start a text on a Pipedrive deal stage change, with no service to run. The catch is replies. Pipedrive has no inbox for texts arriving from outside, so inbound messages need to be written back as notes or activities on the person record, or reps never see them.

Salesforce

Salesforce has its own messaging products and a deep AppExchange. If you're already paying for its messaging tier, that's often the least-friction option. Otherwise, Flow can make HTTP callouts and Apex can do anything, so a direct API build is realistic without a separate server. The tricky part is matching records. One phone number can sit on a Lead, a Contact and a Person Account at once, and an inbound reply has to be matched to the correct one.

Airtable

Airtable automations include a "Run a script" action that can call external APIs, which makes it a surprisingly good front end for small texting workflows such as appointment confirmations or volunteer shifts. Its weakness is that it isn't built to be a consent ledger. If Airtable is your contact list, add explicit fields for opt-in time, opt-in wording and source page. Keep them up to date yourself, because no SMS provider will populate them for you.

GoHighLevel

This is our deepest native integration. Ready installs into GoHighLevel via OAuth as an LC Phone alternative, syncs inbound and outbound messages both ways, and maps each GHL location to its own sub-account so agencies keep every sub-account isolated. Our GHL setup guide walks through it.

For Pipedrive, Salesforce, Airtable, HubSpot and the rest, Ready is an API you call. Inside Ready, automations in the App Library can also start from, or write to, Close, HubSpot, Pipedrive, Salesforce and Zoho CRM with no code, for example texting a contact when a Pipedrive deal changes stage. We don't have native marketplace apps listed inside those CRMs, and if a native app inside your CRM is a hard requirement, pick a vendor that has one.

Close

Connect Close in Ready under Settings, then Integrations, and turn on texting from Close. Your team can then text any Close lead from your Ready number, by logging a Text via Ready activity in Close or with a Close Workflow step that sets the Ready text field.

The sync pitfalls that actually break integrations

1. Duplicate sends

Connectors retry failed steps, CRMs sometimes fire the same trigger twice, and a timeout doesn't tell you whether the provider actually sent the text. Without protection, a retried request becomes a second text. Ready accepts an Idempotency-Key header (any UUID) so a retried request never sends twice. Generate the key from something stable, such as the CRM record ID plus the reminder type, not a fresh random value on every attempt. More on this in how to stop duplicate texts from your SMS API.

2. Phone number formatting

The CRM stores "(212) 555-0199" and the SMS tool stores "+12125550199". Inbound replies then fail to match, or create a second contact, and the thread splits in two. Normalize to E.164 at the point where the number enters the CRM, not at send time. Ready treats a 10-digit US number as +1, but your CRM's matching logic won't be that forgiving.

3. Opt-out drift

This is the most dangerous one. Someone texts STOP. Your SMS provider blocks them, but the CRM still shows them as subscribed, and next month a different tool, or a rep on their personal phone, texts them anyway. On Ready, opt-outs propagate across every campaign on the account, and opted-out numbers are refused up front and not charged. Your CRM still needs to know about them, though. Pull GET /v1/opt-outs on a schedule, or check GET /v1/opt-outs/:phone before a manual send, and write a do-not-text flag back to the record. That list holds only this account's opted-out contacts, so check GET /v1/opt-outs/:phone before another tool texts a number. See the opt-out API post for the full pattern.

4. Replies that never reach the record

One-way connectors are easy. The return path is where most setups stop. If replies land only in the SMS tool's inbox, your reps work from stale records. Decide on day one which system owns the conversation thread. Then build or confirm the inbound path using webhooks (see the two-way SMS API walkthrough and docs.tryready.com).

5. Assuming the SMS tool stores consent

Ready records the sender's opt-in attestation on every bulk send and every API send that sets consent_attested: who sent, to how many and when. That builds an audit trail of your promises. It isn't a per-contact consent record. We don't store each recipient's opt-in time, wording or page URL, and a keyword reply doesn't create one. That record belongs in your CRM, next to the contact. (A contact who signs up on a Ready-hosted opt-in page is the exception: Ready stores that sign-up, with the time, IP address and exact wording, and support@tryready.com can send you a copy.)

6. "Sent" that isn't sent

On the API, a text that falls in the recipient's quiet hours is held (202) only if their window opens within 6 hours, and it is charged only when it goes out; otherwise it is refused with 409 QUIET_HOURS_BLOCK and next_allowed_at, and your integration must resend it then. Campaigns and drips sent from the app wait up to 24 hours. If your connector marks the CRM task "texted" the moment the API call returns, the record and reality disagree. Map 202 to "queued" and 409 QUIET_HOURS_BLOCK to "not sent, retry at next_allowed_at".

7. Batch size and speed

Bulk sends on Ready take at most 100 recipients per call, so a 3,000-contact list is 30 calls. Carrier throughput also caps how fast those calls turn into delivered texts. A fresh standard campaign might run at roughly 1 to 4 segments per second, so a CRM automation that queues thousands of texts at once will drain over minutes, not instantly.

What a direct API call looks like

Whatever triggers it (a Salesforce Flow callout, an Airtable script, a Pipedrive webhook handler), the request is the same:

POST https://api.tryready.com/v1/messages
X-API-Key: <key>
Idempotency-Key: 6f1c2a9e-3b7d-4e1a-9c55-0d2b8e4f7a10
Content-Type: application/json

{"to": "+12125550199", "body": "Hi Dana, confirming your 2 PM consult tomorrow. Reply C to confirm or R to reschedule.", "consent_attested": true}

consent_attested is your promise that this person agreed to receive texts, which is why the consent fields in your CRM matter. The quickstart covers keys and the inbound side.

Worked example: what a CRM reminder flow costs

Here's an example with stated assumptions. A clinic's CRM sends 3,000 appointment reminders a month. Each one is about 140 plain characters with no emoji, so each is 1 segment. Assume about 30% of recipients reply with one short text, which is 900 inbound segments. Replies are billed like sends.

• Segments: 3,000 + 900 = 3,900
• Ready Standard: 3,900 × $0.0075 = $29, plus 3,900 × $0.0045 carrier fee
• Registration: $25/mo for registration + $2 per number

That all-in figure excludes the compliance surcharge. Scrubbing and landline validation are each $0.003 extra per segment when switched on, and both are off by default.

Add one emoji to that reminder and it drops to a 70-character limit, so 140 characters becomes 3 segments, and the outbound part of the bill triples. Check templates before you wire them into an automation.

On price alone, Twilio and GoHighLevel's LC Phone charge less per segment than Ready Standard. If you already run a working Twilio integration and are happy maintaining registration and opt-out logic yourself, that's a legitimate choice. What Ready adds is in-app 10DLC registration (most approvals take 2 to 7 days), opt-out propagation, quiet-hours holds, optional DNC and litigator scrubbing, and sub-accounts for each of your own customers. Those are the parts most CRM integrations end up rebuilding badly.

Picking your path

• One CRM, small team, standard workflows: use a native app if your CRM has a good one.
• A few triggers across tools: use a connector, but add the idempotency key and an opt-out sync flow from day one.
• You're a platform texting for your customers, or volume is high: build on the API, with per-customer sub-accounts and registration. The technical walk-through covers the build.

Whichever path you choose, decide three things before writing the first flow: where consent lives, which system owns the conversation thread, and how opt-outs get back to the CRM. Most integration problems trace back to one of those three being left unanswered.

If you want to test the API path, sign up with a card on file. Your first 20 one-to-one texts are free, so use them to prove the round trip from CRM to text and back before you pay for registration.