From 8b89c283fff22f95804c0b37003e84f0ed081066 Mon Sep 17 00:00:00 2001 From: Brent Anderson Date: Fri, 1 Dec 2023 08:17:38 -0600 Subject: [PATCH] chore(kno-4752): clarify inline identify requires id fields (#348) --- content/managing-recipients/identifying-recipients.mdx | 4 +++- content/reference.mdx | 2 ++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/content/managing-recipients/identifying-recipients.mdx b/content/managing-recipients/identifying-recipients.mdx index 9d65860e..3500ef43 100644 --- a/content/managing-recipients/identifying-recipients.mdx +++ b/content/managing-recipients/identifying-recipients.mdx @@ -48,6 +48,8 @@ While identifying individual recipients is useful, you may also need to identify It's also possible to inline identify recipients while issuing calls to certain resources within Knock. Inline identifying will always upsert the recipients being passed in before executing the remainder of the request. This can be useful for ensuring that your recipients exist within Knock before executing calls that reference those recipients. +You can also inline identify actors in the same way. + Inline identification works with any endpoint that accepts a list of recipients: - [Workflow triggers](/reference#trigger-workflow) @@ -67,7 +69,7 @@ When passing a set of recipients to be inline identified, Knock will guarantee t ## Setting properties while identifying recipients -When identifying recipients you pass a set of properties for the recipient that are persisted. No properties on the recipient are required, although there are some reserved property names for recipients that have special meaning: +When identifying recipients you pass a set of properties for the recipient that are persisted. No properties on the recipient are required except for `id`. Generally, the best practice here is to use your internal identifier for your users as the `id`. There are some reserved property names for recipients that have special meaning: - `name`: The given name of the recipient - `email`: A valid email address to deliver email notifications to diff --git a/content/reference.mdx b/content/reference.mdx index 3036e786..184046d7 100644 --- a/content/reference.mdx +++ b/content/reference.mdx @@ -1190,6 +1190,8 @@ A trigger calls a workflow created via the Knock dashboard. In the `recipients` and `actor` fields in a trigger call, you can optionally include maps full of properties describing a user or an object. These can be properties describing a brand new user/object, or properties describing an update to an existing one. When this data is present in a notify call, Knock will persist it as part of processing the workflow. This is comparable to direct calls to the [identify user](#identify-user) or [set object](#set-object) APIs. +Each recipient and actor must have an `id` field set in addition to other properties (e.g. email, name, or phone number). + See our guides on inline identification [for users](/send-and-manage-data/users#3-inline-identification) and [for objects](/send-and-manage-data/objects#3-set-objects-inline) for more details on this use case. ### Endpoint