Primary email for contact from v1 endpoint

tl;dr

When making requests to

contacts/v1/lists/recently_updated/contacts/recent

, can I get the primary email of a contact by
- taking the first element of the

identity-profiles

array
- from this

identity-profiles

object, taking the unique element of the

identities

array with

“is-primary”: true

Full Context

I’m working on a Hubspot integration that makes requests to the v1 legacy endpoint. In particular, I’m trying to access the primary email of the contacts in the response to

contacts/v1/lists/recently_updated/contacts/recent

.

The documentation for this endpoint is here:
https://legacydocs.hubspot.com/docs/methods/contacts/get_recently_updated_contacts

In the documentation, elements of an

identities

array (in

identity-profiles

) do not have

is-primary

or

is-secondary

properties. Based on our legacy code, I’m guessing that:
- for each element of

identity-profiles

, only one element of the

identities

array has

type

EMAIL

,
- the first element of

identity-profiles

contains the primary email
- the subsequent elements of

identity-profiles

are the record’s merge history

This isn’t explicitly spelled out anywhere I can see though, e.g.

However, what I’m observing when I make these requests today matches what is described in
https://community.hubspot.com/t5/APIs-Integrations/What-is-identity-profiles-in-contact/td-p/232911
in that
-

EMAIL type

identities

have either

“is-primary”: true

or

“is-secondary”: true

- only the first

identity-profile

contains

identities

with

type

EMAIL

.

When did this change? Are these observations correct?

Hey @KJE ,

Welcome to the Community.

Curious why you do not just add that as an additional parameter in your request. For example, this request grabs the primary and any additional email addresses attached to the contact

https://api.hubapi.com/contacts/v1/lists/recently_updated/contacts/recent?hapikey={{hapi}}&property=email&property=hs_additional_emails

> Curious why you do not just add that as an additional parameter in your request.
I did not consider that approach, but it seems like it would work for me! Thank you Dennis!