Per-client support verdict for a single feature, for deciding HOW to build something rather than checking what you already built. Returns one of four verdicts per client: supported, unsupported, mitigated (works with a documented workaround — read the notes), or untested (no data; not the same as unsupported). Also returns the version the verdict came from, every version on record, and how stale the last test is. Feature slugs are not guessable — use search_features first.

Describe the caniemail dataset in use: whether it is live, cached, or bundled; when it was last updated; and whether it is stale. Call this to decide whether to warn a user that answers may be out of date.

Check drafted email HTML and/or CSS against email clients and report only what breaks. Call this after writing an email, before sending. Returns findings at three severities: "error" (unsupported — will not render, use a fallback), "warning" (partial or conditional support — read the notes, usually workable), and "unknown" (never tested on those clients — this is NOT evidence of support; avoid or test). Passing features are never returned. One feature usually yields two or three findings, one per verdict, and a finding carries only what its verdict decides: severity, verdict, clients_affected, client_count, notes and feature_notes. Everything else is in the result's "features" legend, keyed by the slug each finding's "feature" names — look there for the title, the feature URL, last_test_date, and "positions", every place your markup uses it as "line:col-line:col" (with occurrence_count, which is higher than the list when a feature appears more than ten times). "clients_affected" is compressed against the clients you asked for: "*" means all of them and "outlook.*" means all the ones you asked for in that family, with client_count always the exact number. Per-severity advice is in the "guidance" legend rather than repeated on every finding.