Skip to content

Commit dbdc015

Browse files
dan0505claude
andauthored
Document email_verified on the contact object (#678)
* Document email_verified on the contact object The contact object now returns whether its email address has been verified. The field was already accepted on contact create and update. * Show the new field in the full-shape contact response examples Only examples that spell out the whole contact object, and the visitor convert endpoint, which returns a contact rather than a visitor. * Limit the response field to the Preview description The contact object returns email_verified on Preview only, so the released 2.16 description should not advertise it. * Say what a verified email actually means "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. * Correct what inbound mail proves about a verified address 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. * Name only the routes that actually set the field The previous wording described routes that are not reachable today, which read as behaviour rather than intent. * Rewrite email_verified request and response descriptions for accuracy 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 * Reframe email_verified descriptions around proof of ownership 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 * Drop email_verified from the visitor convert response example 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 * Say what omitting email_verified means on create as well as update Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X52yaGBxmKCTMiXQG8rBKe * Say what happens to email_verified when a verified contact's email changes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X52yaGBxmKCTMiXQG8rBKe * Show email_verified in the visitor convert response example Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X52yaGBxmKCTMiXQG8rBKe * Simplify the email_verified request field description Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X52yaGBxmKCTMiXQG8rBKe --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
1 parent 391a4ee commit dbdc015

2 files changed

Lines changed: 44 additions & 4 deletions

File tree

‎descriptions/0/api.intercom.io.yaml‎

Lines changed: 28 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8891,6 +8891,7 @@ paths:
88918891
external_id: '70'
88928892
role: user
88938893
email: joebloggs@intercom.io
8894+
email_verified: false
88948895
phone:
88958896
formatted_phone:
88968897
name: joe bloggs
@@ -8980,6 +8981,7 @@ paths:
89808981
external_id: '70'
89818982
role: user
89828983
email: joebloggs@intercom.io
8984+
email_verified: false
89838985
phone:
89848986
formatted_phone:
89858987
name: joe bloggs
@@ -9174,6 +9176,7 @@ paths:
91749176
external_id: '70'
91759177
role: user
91769178
email: joe@bloggs.com
9179+
email_verified: false
91779180
phone:
91789181
formatted_phone:
91799182
name: Joe Bloggs
@@ -9388,6 +9391,7 @@ paths:
93889391
external_id: '70'
93899392
role: user
93909393
email: joe@bloggs.com
9394+
email_verified: false
93919395
phone:
93929396
formatted_phone:
93939397
name: Joe Bloggs
@@ -10027,6 +10031,7 @@ paths:
1002710031
external_id:
1002810032
role: user
1002910033
email: joebloggs@intercom.io
10034+
email_verified: false
1003010035
phone:
1003110036
formatted_phone:
1003210037
name:
@@ -10188,6 +10193,7 @@ paths:
1018810193
external_id: '70'
1018910194
role: user
1019010195
email: joe@bloggs.com
10196+
email_verified: false
1019110197
phone:
1019210198
formatted_phone:
1019310199
name: Joe Bloggs
@@ -25988,6 +25994,7 @@ paths:
2598825994
external_id:
2598925995
role: user
2599025996
email: foo@bar.com
25997+
email_verified: false
2599125998
phone:
2599225999
formatted_phone:
2599326000
name:
@@ -31527,6 +31534,11 @@ components:
3152731534
type: string
3152831535
description: The contact's email domain.
3152931536
example: example.com
31537+
email_verified:
31538+
type: boolean
31539+
description: >-
31540+
Whether the contact has proved they own their current email address. `true` only when this address was marked verified through the Contacts API (`email_verified: true` on create or update) and has not changed since; it becomes `false` again if the contact's email changes, until the new address is verified. Intercom reuses a lead with a verified email when it later matches an inbound email, or an outbound conversation or ticket, to that address, instead of creating a new lead. Only returned on the Preview version; not present on any released API version.
31541+
example: true
3153031542
phone:
3153131543
type: string
3153231544
nullable: true
@@ -34920,7 +34932,14 @@ components:
3492034932
email_verified:
3492134933
type: boolean
3492234934
nullable: true
34923-
description: Whether the contact's email address has been verified. Set to true to indicate you have verified the contact owns this email address, or false to mark it as unverified. Must be supplied together with an email in the same request; sending it without an email returns a 400. Verifying a lead's email also makes that lead reusable whenever Intercom matches an email address to a contact. When inbound email arrives from an address no user has, or an outbound conversation or ticket is created for one, Intercom reuses a lead with that address whose email is verified, instead of creating a new lead. Leads with an unverified email are not matched this way.
34935+
description: |-
34936+
Whether the contact has proved they own this email address, for example by completing a confirmation link or one-time code you sent to it. Send `email_verified` in the same request as `email`, for example `{"email": "jane@example.com", "email_verified": true}`. A request that includes `email_verified` without `email` fails with a `400`.
34937+
34938+
- `true`: ownership is proved.
34939+
- `false`: ownership is not proved.
34940+
- Omitted: the current verification status stays the same.
34941+
34942+
New contacts start unverified. If you change a verified contact's email, the new address is unverified until you verify it. Only send `true` when you have that proof. When an inbound email, outbound conversation, or ticket matches a verified address, Intercom reuses that lead instead of creating a new one.
3492434943
example: true
3492534944
phone:
3492634945
type: string
@@ -43196,7 +43215,14 @@ components:
4319643215
email_verified:
4319743216
type: boolean
4319843217
nullable: true
43199-
description: Whether the contact's email address has been verified. Set to true to indicate you have verified the contact owns this email address, or false to mark it as unverified. Must be supplied together with an email in the same request; sending it without an email returns a 400. Verifying a lead's email also makes that lead reusable whenever Intercom matches an email address to a contact. When inbound email arrives from an address no user has, or an outbound conversation or ticket is created for one, Intercom reuses a lead with that address whose email is verified, instead of creating a new lead. Leads with an unverified email are not matched this way.
43218+
description: |-
43219+
Whether the contact has proved they own this email address, for example by completing a confirmation link or one-time code you sent to it. Send `email_verified` in the same request as `email`, for example `{"email": "jane@example.com", "email_verified": true}`. A request that includes `email_verified` without `email` fails with a `400`.
43220+
43221+
- `true`: ownership is proved.
43222+
- `false`: ownership is not proved.
43223+
- Omitted: the current verification status stays the same.
43224+
43225+
New contacts start unverified. If you change a verified contact's email, the new address is unverified until you verify it. Only send `true` when you have that proof. When an inbound email, outbound conversation, or ticket matches a verified address, Intercom reuses that lead instead of creating a new one.
4320043226
example: true
4320143227
phone:
4320243228
type: string

‎descriptions/2.16/api.intercom.io.yaml‎

Lines changed: 16 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -28791,7 +28791,14 @@ components:
2879128791
email_verified:
2879228792
type: boolean
2879328793
nullable: true
28794-
description: Whether the contact's email address has been verified. Set to true to indicate you have verified the contact owns this email address, or false to mark it as unverified. Must be supplied together with an email in the same request; sending it without an email returns a 400. Verifying a lead's email also makes that lead reusable whenever Intercom matches an email address to a contact. When inbound email arrives from an address no user has, or an outbound conversation or ticket is created for one, Intercom reuses a lead with that address whose email is verified, instead of creating a new lead. Leads with an unverified email are not matched this way.
28794+
description: |-
28795+
Whether the contact has proved they own this email address, for example by completing a confirmation link or one-time code you sent to it. Send `email_verified` in the same request as `email`, for example `{"email": "jane@example.com", "email_verified": true}`. A request that includes `email_verified` without `email` fails with a `400`.
28796+
28797+
- `true`: ownership is proved.
28798+
- `false`: ownership is not proved.
28799+
- Omitted: the current verification status stays the same.
28800+
28801+
New contacts start unverified. If you change a verified contact's email, the new address is unverified until you verify it. Only send `true` when you have that proof. When an inbound email, outbound conversation, or ticket matches a verified address, Intercom reuses that lead instead of creating a new one.
2879528802
example: true
2879628803
email:
2879728804
type: string
@@ -35530,7 +35537,14 @@ components:
3553035537
email_verified:
3553135538
type: boolean
3553235539
nullable: true
35533-
description: Whether the contact's email address has been verified. Set to true to indicate you have verified the contact owns this email address, or false to mark it as unverified. Must be supplied together with an email in the same request; sending it without an email returns a 400. Verifying a lead's email also makes that lead reusable whenever Intercom matches an email address to a contact. When inbound email arrives from an address no user has, or an outbound conversation or ticket is created for one, Intercom reuses a lead with that address whose email is verified, instead of creating a new lead. Leads with an unverified email are not matched this way.
35540+
description: |-
35541+
Whether the contact has proved they own this email address, for example by completing a confirmation link or one-time code you sent to it. Send `email_verified` in the same request as `email`, for example `{"email": "jane@example.com", "email_verified": true}`. A request that includes `email_verified` without `email` fails with a `400`.
35542+
35543+
- `true`: ownership is proved.
35544+
- `false`: ownership is not proved.
35545+
- Omitted: the current verification status stays the same.
35546+
35547+
New contacts start unverified. If you change a verified contact's email, the new address is unverified until you verify it. Only send `true` when you have that proof. When an inbound email, outbound conversation, or ticket matches a verified address, Intercom reuses that lead instead of creating a new one.
3553435548
example: true
3553535549
phone:
3553635550
type: string

0 commit comments

Comments
 (0)