Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(kno-4752): clarify inline identify requires id fields #348

Merged
merged 1 commit into from
Dec 1, 2023
Merged

chore(kno-4752): clarify inline identify requires id fields #348

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion content/managing-recipients/identifying-recipients.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand All @@ -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
Expand Down
2 changes: 2 additions & 0 deletions content/reference.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
Loading