Textlocal alternatives: moving on after the closure

The closure timetable is on a notice published by Webex Interact, which Textlocal customers were directed to. Textlocal sales stopped on 31 May 2026. Textlocal Messenger closed on 31 July 2026, and the notice says all Textlocal services, messaging, APIs and Proxy stopped on that date. Post-pay accounts were sent a final invoice on 1 August 2026, with payment due by 30 August 2026.

The notice points Textlocal customers to Webex Interact, and says valid prepaid credits could be transferred there after migrating. It also advised customers to export their reports and records before the closure.

When we checked on 16 October 2026, textlocal.com no longer resolved. Anything still pointing at Textlocal's API, a website form or a booking system plug-in, say, is failing, and the texts it thinks it's sending aren't going anywhere.

Every provider is set up a bit differently, and the right one depends on what you used Textlocal for. These are the questions worth asking any of them, us included:

Before you move, gather the things that made your old setup work. Even with Textlocal gone, you may have copies in exports, spreadsheets or the systems that fed it:

CaptiFi Connect is a UK business texting service from CaptiFi Connect Ltd, a sister company of CaptiFi. It covers campaigns to your lists, scheduling, templates with merge fields, a two-way inbox, sender names and a REST API with signed webhooks and test keys.

There are things we don't do, and you should know them before you start: no texts outside the UK, no picture messages, no short codes and no ready-made connectors for named apps (everything connects through the API, webhooks, email to SMS and CSV). If you relied on any of those in Textlocal, we're not the right fit for that part of your setup.

The shape of the change is the same whatever language you use. Requests go to /api/v1 with your key in the Authorization header as a Bearer token, and bodies are JSON of up to 1 MB. A send is POST /api/v1/messages with to (one number or several) and body, plus optional sender, schedule_at and client_ref fields. To text a whole list, create a campaign with POST /api/v1/campaigns and start it with POST /api/v1/campaigns/{id}/send.

Responses come back as data and meta, and errors as an error object with a code, a message and details. Add an Idempotency-Key header to each send so a retry can never send twice, and use client_ref to carry your own reference (an order or booking number, for example) through to the delivery reports.

Delivery reports and replies arrive by webhook: message.sent, message.delivered and message.failed for outbound texts, message.received for replies and opt_out.created for opt-outs. Each one is signed with HMAC SHA-256 so you can check it came from us. The whole API is described in the OpenAPI 3.1 document at /api/v1/openapi.json.

Use a test key for the whole rehearsal. Test keys send nothing and cost nothing; each test text is marked sent, then delivered a few seconds later, and your webhooks receive message.sent and message.delivered as they will in live use. Replies and opt-outs only come from live texts, so message.received and opt_out.created never fire on a test key. Test keys are limited to 50 numbers a request and 300 numbers an hour, which is plenty for a dry run.

When the test runs look right, swap the test key for a live one. Nothing else in your code needs to change. Send one real text to your own phone before the first big send, just to see it arrive.