Customer.io SMS No Longer Means Twilio. Three Things You Give Up, and One the Release Notes Got Wrong

AT&T's plan of reorganisation was filed on 16 December 1982 as Civil Action No. 82-0192. It divested the 22 Bell operating companies and regrouped them into seven regional holding companies. On 1 January 1984, in the Bell System Memorial's phrasing, "the Bell System no longer exists".

What it did not do was let anyone pick a long-distance carrier that morning. The court had required the operating companies to give rival carriers access "equal in type, quality, and price" to AT&T's own—the phrase sits in United States v. American Tel. and Tel. Co., 552 F. Supp. 131, decided 28 February 1983. Equal access then arrived area by area. From 1 September 1984, per the Bell System Memorial, each of the seven regional companies began offering it "in a small number of locations". D Magazine dates the start of the process to August 1984. Both agree on the finish: September 1986.

If you were already an AT&T customer, you waited for a letter. In December 1985, D Magazine reported Southwestern Bell as saying that letters offering the choice "have been distributed to roughly two-thirds of all Dallas customers", with the final wave due the following month. The reward for converting was dialling "1+" instead of the "complicated and lengthy numerical codes now used".

The market opened on paper two years before most people could act on it, and the incumbent's own customers were last in the queue. That is the shape of what Customer.io shipped on 30 July 2026.

TL;DR:

• On 30 July 2026 Customer.io added Sinch, Infobip and Vonage as SMS providers alongside Twilio. You can connect more than one, including two accounts with the same provider—one for the EU, one for North America.
• The four providers are not interchangeable inside Customer.io. Three things differ once you bring your own, and only two of them are actually about the provider you pick. Link shortening is on by default only for Twilio. Inbound reply capture becomes a manual webhook job, per connection. And the composer you get is decided by the date you integrated, not the provider you chose.
• The difference the release notes shout about is no longer true. The 20 July 2026 release note says "You can limit the number of WhatsApp and SMS messages sent via Twilio, but not other vendors". The message frequency limits docs, updated 17 August 2026, now show limits applying to SMS through Twilio, Customer.io, Vonage, Infobip and Sinch alike. Trust the docs, not the release note.
• Twilio traffic routes through Twilio's US region and Customer.io does not support Twilio's regional APIs, which the docs flag as a potential problem for GDPR-style data residency. Sinch is US-region only inside Customer.io. Infobip connects through your account's own API base URL and Vonage through your own account credentials, which is the route to a genuinely non-US setup.
• Two settings to change on day one: turn on Shorten links, and paste your Inbound URL into your provider's console.

What shipped on 30 July 2026

Customer.io stopped being a Twilio-only SMS platform. The release note is short about it: "You can now bring your own provider for SMS messages! Previously, you could only integrate with Twilio or work with Customer.io to set up sending with SMS. You can integrate with one or more providers per workspace to make it easier to message people across different regions or subaccounts."

Before that date you had two options. Connect your own Twilio account, or, if you were based in the US or Canada and sending to the US or Canada, ask Customer.io to run SMS for you. That second option still exists and still goes through Twilio underneath: "behind the scenes, we send through Twilio on your behalf". It is also still the only managed option, and it is still gated on where you are.

Now the SMS get-started page covers four providers. The multi-connection story is the point of the release: "You can connect more than one provider, and you can connect the same provider twice—for example, separate Sinch accounts for US and EU traffic."

Every write-up of this release will tell you that means more choice for global senders. True, and boring. The part worth your afternoon is that the four providers behave differently once they are connected, and that one widely-quoted difference between them has quietly stopped being real.

What actually connects, provider by provider

Customer.io syncs your sender identities from whichever provider you connect: "the phone numbers, sender IDs, or apps you've configured with your provider". You pick one when you compose. What differs is the credential you hand over, what becomes a sender, and what the provider will not do.

	Twilio	Sinch	Infobip	Vonage
Credentials	Account SID, API key SID, API secret	Project ID, access key ID, access key secret	API key plus your account's base URL	Account-level API credentials
What becomes a sender	Phone numbers, short codes, alphanumeric IDs	Each app in your Sinch project	Phone numbers and alphanumeric sender IDs	Each phone number on the account
Region constraint	Routed through Twilio's US region; regional APIs unsupported	Conversation API project must be in Sinch's US region	Your account's own base URL	Your account's own credentials
MMS	Yes	Not documented	Not documented	US numbers only
Link shortening default	On	Off	Off	Off
Managed by Customer.io	Yes, US and Canada only	No	No	No

Sinch

Customer.io connects through the Sinch Conversation API, and the unit of a sender is an app rather than a number. Each app in your Sinch project becomes a sender, and Sinch delivers through that app's configured SMS channel. You need a project ID, an access key ID and an access key secret.

Two things to know before you start. The project has to live in Sinch's US region: "we don't currently support other Sinch regions". And Sinch shows the key secret once, so copy it when it appears rather than going back for it.

When you save, Customer.io validates by listing the apps in your project and syncs each one as a sender. Add apps in Sinch later and nothing appears until you sync the connection again.

Infobip

Infobip needs an API key and something the other providers do not ask for: your account's own API base URL, which "looks like https://xxxxx.api.infobip.com". Infobip shows it next to your API keys. Both phone numbers and alphanumeric sender IDs sync as senders.

Alphanumeric senders carry the sharpest trap in this release, and it is a consent trap rather than a technical one. The docs are blunt: "They're one-way: people can't reply to them, so opt-out keywords like STOP never reach you. Give recipients another way to opt out." Country support varies as well, and some countries require you to register the sender before you can use it. Infobip rejects the message at send time if the destination country does not allow your sender.

You register those sender IDs with Infobip, not with Customer.io. If one does not show up after a sync, check that your API key has permission to list resources.

Vonage

Vonage takes account-level API credentials, and every phone number on the account becomes a sender. Customer.io attaches a delivery webhook to each message, so delivery metrics arrive without setup.

One hard limit: "Vonage supports MMS (image messages) to US numbers only." If you send picture messages to a non-US audience, Vonage is not your provider.

Twilio, and why it is still the default

Twilio remains the only provider Customer.io will run on your behalf, and the only one where link shortening starts switched on. It is also the provider the rest of the platform was built around, which shows up in small places—the fallback inbound URLs later in this post exist for Twilio and nobody else.

Restricted API keys need an exact permission set, and read-only across the group is not enough. Under Iam: Accounts read. Under Messaging: content-templates read and list, messages read and list. Under Phone-numbers: active-numbers read and list, available-numbers list, event-streams, event-type read and list, and subscription read, list and create. That last verb is the one a read-only key will not have.

The release notes say non-Twilio SMS can't be frequency capped. The docs now say it can

This is the claim to get right, because it is the one most likely to send you down the wrong architecture.

On 20 July 2026, ten days before bring-your-own-provider shipped, Customer.io made its message frequency limit channel-based. The release note announcing it ended with this sentence: "You can limit the number of WhatsApp and SMS messages sent via Twilio, but not other vendors." As of 19 August 2026 that sentence is still on the release notes page.

The message frequency limits overview, updated 17 August 2026, disagrees. Its channel table now reads:

Channel	Sent through	Can limits apply?
Email	Customer.io	Yes
Email	Custom SMTP	Yes
Push notifications	n/a	Yes
Webhooks (Send and receive data)	n/a	Yes
SMS	Twilio	Yes
SMS	Customer.io	Yes
SMS	Vonage	Yes
SMS	Infobip	Yes
SMS	Sinch	Yes
WhatsApp	Twilio	Yes, but counts towards the SMS limit
WhatsApp	Meta/WhatsApp Business	Yes
LINE	n/a	Yes
In-app	n/a	No
Inbox messages	n/a	No
Slack	n/a	No

The page's own prose says the same thing without the vendor rows: "You can apply your workspace's message limits to email, push notifications, LINE, webhooks, SMS and WhatsApp message channels." The sentence that used to carve out non-Twilio SMS has been deleted. The set-up page corroborates it, listing the configurable message types as "Email, SMS, WhatsApp, LINE, Push notification, or Send and receive data (for webhooks)" with no vendor qualifier.

So the vendor carve-out the release note describes is not in the documentation any more. Nor is it announced as a change: there is no release note after 30 July 2026 mentioning message limits, SMS providers, Sinch, Infobip or Vonage. The only marker is the Updated stamp on the overview page reading 17 August 2026.

Our position is to trust the docs page over the release note. A release note is a dated record of what shipped on a day; the overview page is maintained as a description of the product now, and it has been touched more recently. Two docs pages agree with each other and only the older release note dissents.

That does not make the caveat harmless. Verify it in your own workspace before you rely on it. Create a limit, include SMS, attach it to one automation, then confirm a capped send is recorded as Undeliverable and check the reason given on the delivery. Ten minutes of checking beats trusting either page.

Two numbers worth separating while you are in there, because they get conflated. The maximum time frame for a message limit is 31 days. The maximum retry window is 48 hours. Different settings, different jobs. Customer.io's guidance is to "set your retry window to at least as long as your message limit timeframe", because a shorter window will not succeed as often as you would want.

The mechanics of how limits count—per profile rather than per campaign, on a rolling window rather than calendar days, and doing nothing at all until you attach them—have not changed. Those still work as our breakdown of channel-based limits describes, and that post's opt-in warning is the one that catches most teams. Creating a limit changes nothing until you assign it, workflow by workflow.

One piece of housekeeping, since the same rule should apply to us. That post states the Twilio-only vendor split as fact, and quotes the docs sentence that has since been deleted. It was right when we published it on 20 July 2026 and it is wrong now, so it is being corrected. If you read it before this one, the vendor split is the part to ignore. What the change does mean is less hand-built counting logic. If you moved to Sinch or Infobip and built segment-based frequency rules to compensate, some of that suppression and frequency management work may now be redundant. Check before you tear it out.

The composer you get depends on when you integrated, not who you chose

This is the asymmetry people misdiagnose, because it looks like a provider difference and is not.

The get-started page splits on a date, not a vendor:

• "If you integrated your SMS provider before July 30, 2026, then you write messages in the classic SMS composer."
• "If you integrated your SMS provider July 30, 2026 or after, then you write messages in Design Studio…"

Integrate on or after that date and you get sender selection from your synced identities, Liquid personalisation, preview against a real profile's data, image attachment for MMS, and a test send to yourself. Integrate before it and you get the classic composer, whatever provider you are on.

Which produces the awkward case. A workspace that connected Twilio in 2024 does not earn the new composer by connecting Sinch in 2026. And it cannot connect Sinch at all without asking: "If you integrated Twilio before July 30, 2026 and want to integrate with another provider, reach out to your CSM to request access. If you don't have a CSM, reach out to [email protected]."

That is the equal access phase-in, restated. The capability shipped for everyone and arrived for new integrations first, with the incumbent's existing customers waiting for someone to write to them.

Link shortening is off unless you turn it on

Twilio setups get link shortening switched on. Everyone else does not, and the docs say so in two places that read slightly differently.

In the delivery settings list: "Shorten links (off by default): we shorten the links in your messages so tracked links fit within your character limit." In the character-limits section: "It's on by default when you set up Twilio; for other providers, turn on Shorten links in your delivery settings." Read together: the toggle's default is off, Twilio integrations get it flipped on for them, and you should look at the actual switch rather than assume either.

One structural detail matters more than the default. Delivery settings are workspace-wide: "These settings apply to every provider you connect on this page—they're workspace-wide, not per-connection." You cannot shorten links for your EU Infobip connection and leave them long for North America. It is one switch for everything.

Why this is a send failure rather than a reporting gap: SMS gives you 160 characters, and a tracked link is long. Shortening brings it back to something you can plan around. Customer.io publishes the cost: "If you don't use a custom domain, shortened links consume between 26 and 36 characters (out of the 160-maximum for SMS)."

Smart encoding is the other half of the character budget, and it is on by default for everyone. It swaps special characters for GSM 7-bit equivalents "so a stray curly quote doesn't drop your limit to 70 characters per message". Here is what those two figures do to the space you actually get to write in.

Characters left for your copy, out of the 160-character SMS limit. The bottom two rows assume smart encoding is switched off, which is not the default. Sources: Customer.io's SMS get-started page for the 160 and 70 figures, and its link-shortening page for the 26–36 character link cost. The three combined rows are subtraction from those two published figures.

Scenario	Characters left for your copy
Smart encoding on, no tracked link	160
One shortened link, best case (26 characters)	134
One shortened link, worst case (36 characters)	124
One special character, smart encoding off	70
Special character and a shortened link, worst case	34

Two more details from the link-shortening page before you plan a campaign around short links. They expire after 90 days, extendable on request for Premium and Enterprise plans, which matters for evergreen automations more than broadcasts. And custom short-link domains are limited: one on any Customer.io plan, up to ten on Premium and above, shared across SMS and WhatsApp, and never the same domain you use for email link tracking.

Delivery reports are automatic. Replies are not

Customer.io is even-handed on metrics. It records sent, delivered, bounced, clicked and converted "for every provider", in the UI, in reporting webhooks and in data warehouse exports. Delivery reports need no setup at all: "For every provider, we attach a delivery-report callback to each message we send, so delivered and bounced metrics arrive on their own."

Inbound replies are the opposite. Customer.io generates a unique Inbound URL for each connection, and you paste it into your provider's console by hand. The inbound messages guide names the exact setting per provider:

Provider	Where the Inbound URL goes
Twilio	The A message comes in webhook on your numbers, or your messaging service's Inbound Request Config
Sinch	The callback URL on your Sinch Conversation API app
Infobip	The inbound (MO) notify URL in your Infobip portal
Vonage	The Inbound URL on your Vonage application

If Customer.io manages SMS for you, "this is already done". Bring your own provider and it is on you, per connection—each Inbound URL is unique to its connection, so you cannot reuse one across two.

This is the migration step that goes quiet rather than loud. Reply-triggered automations do not error when the webhook is missing. They simply stop firing, because Customer.io never sees the reply. If you have built segments off inbound keywords, or an automation that responds when someone texts back, test one reply end to end before you consider the switch done.

Two Twilio-specific notes worth carrying over. Some Twilio integrations do not show an Inbound URL on the connection page at all; where that happens you point the A message comes in webhook at https://track.customer.io/inbound/twilio/sms for US workspaces or https://track-eu.customer.io/inbound/twilio/sms for EU. And Twilio sends its own auto-reply when someone texts STOP, outside Customer.io: "This message doesn't go through Customer.io and isn't logged by us." Move off Twilio and that reply stops arriving. Whether that is a loss depends on whether you knew it was happening.

Whichever provider you use, replies resolve to people most reliably when you store phone numbers as a phone attribute in E.164 format. Customer.io will try to parse other formats, and admits the bias: "We use Google's libphonenumber library to parse phone numbers, and we skew towards US and Canadian numbers." For a non-US audience that is not a detail to leave to chance.

What does get better: regional routing

Here is the honest case for switching, and it is strong enough to carry the rest.

Twilio inside Customer.io is US-routed and cannot be moved: "You can send messages to people anywhere in the world, but we route data through Twilio's US region. We don't support Twilio's regional APIs. This might be a problem if you have strict data residency requirements for things like GDPR compliance requiring EU data processing."

Sinch does not solve that, because Customer.io only supports Sinch's US region. Infobip and Vonage do change the picture, though the precise claim is narrower than "EU data residency". What the docs support is this: you connect through your own Infobip base URL or your own Vonage credentials. The account and its regional configuration are yours, rather than a US region you cannot opt out of. Whether that satisfies your legal team is a question for them and your provider contract, not for a docs page.

Then there is the argument nobody makes in launch posts: your exposure to bad traffic is regional, so a single global route is a single global risk. Isabelle Paradis, writing for the Mobile Ecosystem Forum in January 2025, puts artificially inflated traffic at "5-40% of all international A2P SMS traffic, depending on the region". Citing Mobilesquared's 2024 report A2P SMS Under Siege, she reports that businesses lost "US$1.6 billion" to it in 2023.

That is fraud exposure rather than a delivery-rate figure, and it is worth being precise about the difference. Nobody reputable publishes per-country delivery rates. What the AIT numbers do establish is that the economics of A2P messaging differ by region by something like an eight-fold factor. That alone is a reason to be able to choose a route per region rather than accept one.

Which is what the multi-connection support is for. Customer.io's release note frames it as "one provider for EU, another for North America, or multiple subaccounts within one provider". If you send to two regions with materially different route quality, that is now expressible in the product rather than in a second workspace. Teams already running native WhatsApp and LINE for a non-US audience will recognise the pattern. Your channel mix stops being a US-first design with exceptions bolted on.

We consolidated two Customer.io workspaces into one for Kip, Australia's leading pet boarding and daycare provider, merging over 200,000 profiles and 80+ campaigns into a single workspace. That job existed for the same reason multi-provider support matters. Teams split workspaces to work around a platform constraint, then pay the reporting and segmentation cost forever. Two connections in one workspace is the better answer.

One thing that works exactly as it should

Opt-outs are provider-blind, and Customer.io got this right.

Text an opt-out keyword to any of your senders and, per the opt-out keyword docs, "we mark them as opted out and stop sending them SMS from every provider you've connected". Not just the provider that received it. START or UNSTOP reverses it. The full keyword set is STOP, CANCEL, UNSUBSCRIBE, OPTOUT, END, QUIT, REVOKE and STOPALL to opt out; START and UNSTOP to opt back in; HELP and INFO for help.

The design decision behind that deserves saying out loud. A consent record that lived per connection would be a compliance incident waiting for its first provider migration—someone who opted out of your Twilio sender in 2025 starts receiving Infobip messages in 2026. Customer.io stores the opt-out against the person, so adding a provider cannot resurrect them.

The alphanumeric case is handled sensibly too. People cannot reply to an alphanumeric sender, so no opt-out can arrive through one, but "opt-outs captured on your other senders still apply to your alphanumeric sends". That is the right default, and it is still not a substitute for giving people a way out. If your only sender is alphanumeric, you need another opt-out route, and channel subscription preferences are the obvious one.

The switch decision, in four questions

No recommendation, because the answer is genuinely different by workspace. Four questions, and what each answer means.

Question	If yes	If no
Do you send SMS outside the US?	Switching is likely worth it. Twilio inside Customer.io is US-routed with no regional option, and Vonage or Infobip put the account and its region under your control.	Twilio, or Customer.io-managed Twilio, is the lower-effort choice. Nothing here is a reason to move.
Do you send MMS to non-US numbers?	Rule out Vonage. Its MMS support is US numbers only.	Vonage stays on the list.
Are you already on Twilio?	You are behind the CSM gate. Ask for access before you plan anything, and expect to keep the classic composer even after a second provider is connected.	You get Design Studio and multi-provider from the start. Connect what you need.
Do you have reply-triggered automations?	Budget the inbound webhook work per connection and test a live reply. This is the step that fails silently.	Delivery reports arrive on their own. Nothing to configure.

And two settings to change on day one, whichever provider you land on. Turn on Shorten links in delivery settings, remembering it applies workspace-wide. Then paste each connection's Inbound URL into that provider's console.

One operational note that will annoy someone eventually: you cannot edit credentials in place. "To change a connection's credentials—for example, when you rotate keys with your provider—disconnect it, then connect again with your new values." Disconnecting stops sending through that provider immediately and removes its senders from the composer, so a key rotation is a short outage rather than an edit. Schedule it.

If you would rather someone else ran the provider evaluation, moved the connections and tested the inbound path before it goes live, that is what our Customer.io work covers. Tell us where you send today and we will tell you whether switching is worth the afternoon.

Frequently asked questions

Can I use Customer.io for SMS without a Twilio account?

Yes, since 30 July 2026. You can connect Sinch, Infobip or Vonage instead and never touch Twilio. The one exception is the managed option. Ask Customer.io to run SMS for you and it still goes through Twilio underneath. It is also only offered to businesses based in the US or Canada, sending to people in the US or Canada.

Which SMS providers does Customer.io support in 2026?

Four: Twilio, Sinch, Infobip and Vonage. Sinch connects through the Sinch Conversation API and needs a project in Sinch's US region. Infobip needs an API key and your account's own base URL. Vonage needs account-level API credentials. Twilio needs an Account SID, API key SID and API secret.

Do Customer.io message frequency limits apply to SMS sent through Sinch or Infobip?

According to the docs, yes. The message frequency limits overview page, updated 17 August 2026, lists SMS through Twilio, Customer.io, Vonage, Infobip and Sinch as all supporting limits. The set-up page agrees, listing SMS as a configurable channel with no vendor qualifier. The 20 July 2026 release note still says the opposite—"You can limit the number of WhatsApp and SMS messages sent via Twilio, but not other vendors"—and has not been updated. Verify it in your own workspace before you depend on it.

Can I connect more than one SMS provider to one Customer.io workspace?

Yes, and you can connect the same provider twice. The docs give separate Sinch accounts for US and EU traffic as the example. The release note frames the use case as "one provider for EU, another for North America, or multiple subaccounts within one provider". Each connection syncs its own senders and gets its own Inbound URL.

Does Customer.io support EU data residency for SMS?

Not through Twilio. Customer.io routes Twilio traffic through Twilio's US region and does not support Twilio's regional APIs, which the docs flag as a potential problem for GDPR compliance requiring EU data processing. Sinch is also US-region only inside Customer.io. Infobip and Vonage connect through your own account, using your Infobip base URL or your Vonage credentials, so the regional configuration is yours. That is a weaker claim than guaranteed EU residency, and worth confirming with your provider.

Why can't I see the option to add a second SMS provider?

Because you integrated Twilio before 30 July 2026. Those workspaces need access granted: "reach out to your CSM to request access. If you don't have a CSM, reach out to [email protected]." It is a deliberate gate rather than a bug.

Do I have to reconfigure opt-outs if I change SMS provider?

No. Opt-outs are stored against the person, not the connection. When someone texts STOP to any of your senders, Customer.io stops sending them SMS from every provider you have connected, so adding or swapping a provider cannot resurrect someone who opted out.

Does switching SMS provider mean re-registering as a sender?

Plan on it. Customer.io's docs do not say registrations transfer between providers, and they are clear that the requirement follows you: "You'll also have to articulate your SMS use cases when you register as a sender—regardless of who you register with." Registration happens with your provider and the carriers rather than with Customer.io. Treat a provider change as a new registration until your new provider tells you otherwise. Our post on carrier registration covers what that process involves.

Will my SMS replies still trigger automations after I switch provider?

Only after you set up the inbound webhook. Delivery reports are automatic for every provider, but inbound replies need each connection's Inbound URL pasted into that provider's console. Until you do it, reply-triggered automations stop firing without producing an error. Test one live reply before you call the migration finished.

Why does my Customer.io SMS composer look different from a colleague's?

Because your workspaces integrated SMS on different sides of 30 July 2026. Integrate before that date and you write in the classic SMS composer; on or after it and you write in Design Studio. It is the integration date that decides, not the provider, and connecting a second provider to an older workspace does not upgrade the composer.

Does Vonage support MMS in Customer.io?

To US numbers only. The docs state it plainly: "Vonage supports MMS (image messages) to US numbers only." If picture messaging to a non-US audience is part of your programme, Vonage is the wrong choice.

Can people reply STOP to an Infobip alphanumeric sender?

No. Alphanumeric sender IDs are one-way, so "opt-out keywords like STOP never reach you". Opt-outs captured on your other senders do still apply to your alphanumeric sends, but if alphanumeric is your only sender you must give people another way out. Country support varies too, and some countries require you to register the sender with Infobip first.

How do I change the API key on an existing SMS connection?

You cannot edit it in place. "To change a connection's credentials—for example, when you rotate keys with your provider—disconnect it, then connect again with your new values." Disconnecting stops sending through that provider immediately and removes its senders from the composer, so treat a key rotation as a short scheduled outage.

Do link shortening and smart encoding work the same for every provider?

The settings are shared, the defaults are not. Both live in workspace-wide delivery settings that "apply to every provider you connect on this page". Smart encoding is on by default for everyone. Link shortening is on by default only when you set up Twilio; for Sinch, Infobip and Vonage you turn it on yourself.

Sources

• SMS/MMS: Get started. Customer.io Docs.
• Message frequency limits: overview. Customer.io Docs, updated 17 August 2026.
• Set up message frequency limits. Customer.io Docs.
• Getting started with inbound messages. Customer.io Docs, updated 17 August 2026.
• SMS: Link shortening. Customer.io Docs, updated 17 August 2026.
• Opt-out keyword handling. Customer.io Docs, updated 17 August 2026.
• Customer.io release notes, for "Set up SMS with Sinch, Infobip, or Vonage" (30 July 2026) and "Set up channel-based message limits" (20 July 2026).
• Sinch Conversation API documentation. Sinch.
• AIT in A2P Messaging: The silent predator. Isabelle Paradis, Mobile Ecosystem Forum, 8 January 2025, citing Mobilesquared, A2P SMS Under Siege, 2024.
• AT&T Divestiture: Plan of Reorganization. Bell System Memorial, on the plan filed 16 December 1982 in Civil Action No. 82-0192.
• United States v. American Tel. and Tel. Co., 552 F. Supp. 131 (D.D.C. 1983). Justia, decided 28 February 1983.
• Consumer Notes: Equal Access Long-Distance Dialing. D Magazine, December 1985.