Verification log

July 30, 2026 · View on GitHub

What was actually checked, when, and how. Each revalidation pass appends a section; nothing is rewritten, so the drift in a vendor's support arrangements is readable over time.

Twilio — 2026-07-30

Method. Four layers, in escalating order, because each one failed for a different reason:

HTTP status and redirect observation on every target (curl -o /dev/null -w '%{http_code} -> %{redirect_url}', browser user agent, 20s timeout).
Full page reads of /en-us/support-plans, /en-us/help/abuse, /en-us/developers.
Raw-HTML mailto: href extraction on live www.twilio.com pages — the only reliable way to get an address off a page whose prose is client-rendered.
Wayback Machine snapshots of the pre-migration support.twilio.com Zendesk, to read help-centre article bodies. This is the step that made the entry real; see below.

Also: the Discord invite code resolved against discord.com/api/v10/invites/, which is the only way to tell a live vanity redirect from a live invite.

Why the archive was necessary, and why it is legitimate

help.twilio.com is a client-rendered single-page app. It returns HTTP 200 with nothing but <title>Twilio Help Center</title> to every non-browser fetcher tried, and its /api/v2/help_center/en-us/articles/<id>.json path returns the same SPA shell rather than JSON — so it is not a stock Zendesk instance addressable through the Zendesk API. Its JS entry point (main.081580c71f891a32.js, 5 KB) is a loader with no API base URL in it.

The way through: support.twilio.com, the Zendesk help centre that help.twilio.com replaced, was server-rendered, and article IDs were preserved across the migration. A Wayback snapshot of support.twilio.com/hc/en-us/articles/<id>-<slug> therefore yields the article body, with mailto: hrefs and HTML tables intact.

The snapshots read are dated, and each claim below carries its snapshot date. A fact read this way is a confirmed reading of Twilio's own published text at that date — not proof the text is unchanged today. Where a fact was independently corroborated against a live page, that is noted.

Articles read: 360048500694 (Contacting Twilio Support, snapshot 2024-11-08), 223136087 (support ticket priority levels explained, 2024-07-18), 223136127 (Twilio Support business hours), 223136447 (Reporting SMS spam or unwanted calls, 2024-02-21 — five days before that host's reported EOL, so the last state of the pre-migration article), 11918653080475 (submitting a ticket without logging in), 360023394914 (Contacting Twilio SendGrid Support).

The email question, settled

This was the point of the exercise, so it gets its own section.

Twilio publishes no general support email address. Article 360048500694 exists specifically to explain how to contact Twilio support, and it contains zero mailto: links. Every route it gives is help.twilio.com or the Console. Any support@twilio.com or help@twilio.com in circulation is someone's inference.

The spam address is misprinted by Twilio itself. In article 223136447:

Report suspected abuse at <a href=".../www.twilio.com/help/abuse">https://www.twilio.com/help/abuse</a>
or <a href="mailto:stopspam@twilio.com">spam@twilio<wbr>.com</a>.

Visible link text: spam@twilio.com. Actual mailto: target: stopspam@twilio.com. They disagree. The href is the operative address; the printed string is what every scraper, search index and language model reproduces. Both are recorded — stopspam@ as the channel, spam@ in known_dead with the explanation.

fraud@twilio.com is genuine, and is the only address confirmed twice independently: as a live raw-HTML mailto: href on https://www.twilio.com/docs/usage/fraud-response-guide/engage, and in Wayback snapshot 20260419215717 of the same page.

abuse@sendgrid.com remains referenced only — the SendGrid abuse-awareness docs are client-rendered and yielded no mailto: to raw-HTML extraction.

The plan/channel matrix, from article 360048500694

Previously referenced and partly guessed; now confirmed, read as an HTML table:

Plan	Help Center Assistant	Direct submit-a-ticket link	Live chat	Phone support
Developer	✔	✘	✘	✘
Production	✔	✔	✔	✘
Business	✔	✔	✔	✔
Personalized	✔	✔	✔	✔

Same article: all customers get a ticket-form response "usually within 24 hours"; and these products are ticket-only regardless of plan — Programmable Video, Conversations, Studio, REST API, Functions/Serverless, Twilio CLI, Event Streams, Sync, Notify, Frontline, NTS.

Priority definitions, from article 223136087

Verbatim structure, previously only inferrable from the support-plans page's row labels:

Priority 1: Business critical. Only available for production applications. Complete loss of service, or a significant feature completely unavailable with no workaround. Excludes development issues and staging environments.
Priority 2: Degraded service. Intermittent issues and reduced quality of service. A workaround may be available. Also excludes development and staging.
Priority 3: General issue. Product questions, feature requests, development issues.

Two operationally significant additions: tickets default to Priority 3 if the customer sets none, and Twilio reserves the right to reclassify, stating that reclassification is used almost exclusively to downgrade a P1 that is really a non-production setup issue or a how-to question.

Business hours, from article 223136127

Roughly 09:00–18:00 Mon–Fri, follow-the-sun across Americas, EMEA and APAC, with per-country holiday calendars (Brazil, Canada, Colombia, Mexico, US; Czechia, Estonia, France, Germany ×2, Ireland, Netherlands, Poland, Serbia, Spain, Sweden, UK; Australia, Hong Kong, India, Japan, Singapore). Weekends and local holidays are not standard business hours and staffing is reduced — but P1 and P2 continue to be prioritised through them. So a "business hours" SLA is regional, and computing elapsed time against one needs the right country's calendar.

help.twilio.com → "Ask AI" (top right) → ask about account access → ask to contact support → choose "Can't Login? Submit ticket without logging in".

The caveat is the valuable part: a ticket filed this way is handled as if no plan is on file, so a paid plan's guaranteed response does not apply and it is triaged on priority alone. Recover the login first unless the login itself is the problem.

SendGrid, from article 360023394914

Its own help centre, and — unlike Twilio proper — no unauthenticated requests are accepted at all. Hours: ticket 24/7, chat 24/7 (paid only), phone 07:00–17:00 MST Mon–Fri (paid only).

Confirmed by direct reach

Target	Observed
`https://help.twilio.com/`	200 (SPA shell)
`https://help.twilio.com/hc/en-us/requests/new`	200
`https://help.twilio.com/support-plans`	200
`https://help.twilio.com/articles/223136447`	200 (shell only)
`https://help.twilio.com/articles/223136527`	200 (shell only)
`https://console.twilio.com/us1/develop/support/tickets`	200, lands on login gate
`https://www.twilio.com/en-us/support-plans`	200, read in full
`https://www.twilio.com/en-us/support-plans/cdp`	200
`https://www.twilio.com/en-us/help/abuse`	200, form fields read
`https://www.twilio.com/en-us/help/contact-sales`	200
`https://www.twilio.com/help/sales.html`	301 → `/en-us/help/sales`, also 200
`https://www.twilio.com/docs/usage/fraud-response-guide/engage`	200, `mailto:fraud@twilio.com` in raw HTML
`https://status.twilio.com/`	200
`https://security.twilio.com/`	200
`https://stackoverflow.com/collectives/twilio`	200
`https://www.twilio.com/en-us/developers`	200, read in full
`https://www.twilio.com/en-us/legal/twilio-discord-faq`	200
`https://www.twilio.com/docs/usage/fraud-response-guide`	200
`https://www.twilio.com/en-us/legal/aup`	200
`https://github.com/twilio`	200

Plan tiers, prices and per-tier response times read directly off /en-us/support-plans.

Still `referenced` — named by a Twilio source, not reached

abuse@sendgrid.com — SendGrid abuse-awareness docs, client-rendered.
r/twilio — linked from the Developer Hub; direct fetch returns 403 to non-browser user agents.
The Discord server — linked from the Developer Hub, with no stable invite URL published there.
support.twilio.com EOL date of 2024-02-27 — from a search result, not from a Twilio page. The 2024-02-21 snapshot being the last available one is consistent with it, but the date itself is not confirmed.

Dead — checked, does not work

Target	Observed	Note
`help@twilio.com`	No Twilio-published source; the how-to-contact-support article has no `mailto:` at all	Recorded as non-existent, not merely unverified.
`spam@twilio.com`	Printed as link text in article 223136447 whose `mailto:` href is `stopspam@twilio.com`	The two disagree. Trust the href.
`https://community.twilio.com/`	Connection failure, host does not resolve	The retired Twilio Forums; final announcement was the move to the Stack Overflow Collective.
`https://www.twilio.com/en-us/community`	404	Frequently cited as the community landing page. It is not one.
`https://www.twilio.com/community`	404	`twilio.com/community` 301s here.
`https://discord.gg/twilio`	301 → `discord.com/invite/twilio`; invites API returns `{"message":"Unknown Invite","code":10006}`	A live redirect fronting a dead invite. Invisible to a link checker.
`https://www.twilio.com/en-us/legal/support-plans`	404	`twilio.com/legal/support-plans` 301s here — a dead end behind a live redirect.
`https://www.twilio.com/en-us/legal/acceptable-use-policy`	404	The AUP is at `/en-us/legal/aup`.
`https://www.twilio.com/en-us/legal/report-abuse`	404	The abuse route is `/en-us/help/abuse`.
`https://support.twilio.com/`	302 → `/hc` → 301 → `/hc/en-us` → 403	Legacy host, still widely linked and indexed. Article IDs resolve under `help.twilio.com/articles/<id>`; snapshots of this host are how the bodies were read.

What this pass established about verification itself

Four observations, all from checking one vendor, and all of them now shape support-revalidate and support-add-service:

A 200 can front an empty page. Client-rendered help centres return 200 with no content to a fetcher. Status codes prove the host is up and nothing about the page.
A 301 can front a dead resource. discord.gg/twilio redirects cleanly to an expired invite. Any link checker following redirect chains reports it healthy.
A 403 does not mean gone. support.twilio.com/hc/en-us bot-walls fetchers while remaining perfectly usable in a browser.
Link text and mailto: href can disagree, and when they do, everything downstream of a text scrape is wrong while everything downstream of a link check is right. Extract hrefs, not prose.

Hence evidence is required on any channel claiming confirmed, and scripts/check_registry.py deliberately does not check reachability — a status code is not a verdict.

Not verified

The skills have not been run end to end against a live Twilio ticket. Nothing below the registry — drafting, sending, the follow-up clock — has been exercised on a real support interaction. That is why the plugin is badged work-in-progress.