According to the API Docs, the notifyRecipients value should be a string values that returns the email addresses of the users who are assigned to be notified of the form submission. This returns the email address on some forms but then returns numerical values (the value of the "remoteId" from the Owners API) on other forms.
I've seen those
remoteId values appear in the forms tool UI as well on some occasions. I seem to recall the IDs appearing when the user was deleted, but I'd like to take a closer look.
Can you share the following?
- Your Hub ID.
- The request URL you are using (I assume it's this endpoint)
- Some of the form IDs (
guid) which show
remoteIdvalues instead of email strings.
Form Guid: 3f8ce33d-9324-4efd-a40d-1db030514408
Form Guid: e27e4d27-4540-4bd4-b2c8-c2e8890333ad
these have active users as the recipients of the form notifications on them.
Thanks for sharing that information.
The definition of
notifyRecipients should be updated.
Through testing, I've confirmed that the
notifyRecipients field will:
- Contain the user IDs (
remoteId) of active account users.
- Contain the email addresses (as strings) of deactivated or non-existent users.
For example, form
There is an active user in your account with the ID
375639 but none with the email
email@example.com. As such, the system returns the
remoteId for the active user and the full email address of the non-existent user.
The same goes for deactivated users like
firstname.lastname@example.org on form
We're conducting an audit of our developer documentation at the moment and I'll be sure this information is corrected. Apologies for the confusion!
Is there a reason why it can't just contain the email address for both active and non-active? This still means that while its awesome to be able to pull this, we have to pull additional api requests just to marry the data up and get the correct users email addresses.