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

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

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