{identifier} path parameter rather than a single fixed ID type. This flexible design lets you reference a resource using either its Shilo-generated UUID or an ID from your own system, without needing a separate lookup step first. Understanding which identifier to use—and when—keeps your integration code simple and reduces round trips.
The prefix:value Pattern
Identifiers that are not plain UUIDs use a prefix:value format. The prefix tells Shilo which ID namespace you are referencing. For example:
call_event_id:ee6f2136-b94a-4438-9335-3acf5b2a0d31— look up by call event IDexternal_recording_id:rec-001— look up by therecording_idyou provided at submissionexternal_user_id:agent-123— look up a user by your system’s user IDexternal_contact_id:contact-456— look up a contact by your CRM’s contact ID
Identifier Reference by Resource
Calls
Contacts
Users
Appointments
Roleplays
Using External IDs Throughout Your Integration
Shilo’s external ID support means you can submit a call using your ownrecording_id and later retrieve its analysis without ever storing Shilo’s internal UUID. The same principle applies to users and contacts: pass your own IDs at call submission time, and use external_user_id: and external_contact_id: prefixes everywhere you need to look them up.
Immediately after submitting a call, use
call_event_id:{uuid} as the identifier because the Shilo call UUID may not be available yet. Once analysis completes and you have retrieved the full call object, you can switch to the stable Shilo UUID for any subsequent lookups.