Skip to content

Document email_verified on the contact object - #678

Open
dan0505 wants to merge 13 commits into
mainfrom
document-contact-email-verified-response
Open

dan0505 wants to merge 13 commits into
mainfrom
document-contact-email-verified-response

Conversation

@dan0505

@dan0505 dan0505 commented Sep 23, 2026 •

Copy link
Copy Markdown
Contributor

Why?

Callers can set email_verified when creating or updating a contact, but the descriptions never said what "verified" means or when to send it, and nothing returned the value. The Preview version now returns it, so the read side needs documenting and the write-side text needs to describe the same meaning.

How?

Rewrites the email_verified request descriptions on 2.16 and Preview around proof of ownership, with an example and a warning against marking unproven addresses. Adds the field to the Preview contact schema and to the response examples that spell out the whole contact object.

Notes for reviewers

The 2.16 edits are description text only; no schema or response shape changes on a released version. The API behaviour this documents is live.

Generated with Claude Code

dan0505 and others added 13 commits September 22, 2026 16:10
The contact object now returns whether its email address has been
verified. The field was already accepted on contact create and update.
Only examples that spell out the whole contact object, and the visitor
convert endpoint, which returns a contact rather than a visitor.
The contact object returns email_verified on Preview only, so the released
2.16 description should not advertise it.
"Has been verified" read as though we had checked the address ourselves. It
can equally be your own assertion, so the description now names both
origins and says the field does not distinguish them.
Mail arriving from an address marks it verified on its own, so the previous
wording overstated the evidence by tying it to sender domain
authentication. Also names file import, and drops the signed-identity
routes, which are not available to every workspace.
The previous wording described routes that are not reachable today, which
read as behaviour rather than intent.
Correct the request-side semantics on the create and update contact
request schemas for the 2.16 and Preview specs, and correct the
Preview-only response field description on the contact schema to drop
the CSV-import and inbound-mail claims that no longer apply.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X52yaGBxmKCTMiXQG8rBKe
Describe the request and response fields in terms of proving
ownership of an email address rather than a bare verified/unverified
state, with a worked request-body example.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X52yaGBxmKCTMiXQG8rBKe
The convert visitor endpoint does not return the field, so its example
should not show it.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X52yaGBxmKCTMiXQG8rBKe

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant