Identify

identify calls associate a user with a set of traits where a track event records something that happened at a point in time, an identify records who someone is — it upserts the user profile rather than appending to their event history identify calls are not counted as events, carry no event timestamp, and cannot be used to trigger downstream automation when you need both — for example on account creation — send an identify to establish the profile and a track event such as user created to mark the occurrence all identify calls must include the following properties in the payload property type required? description type string required identify userid string required id # of the identified user (or email address) traits object required user traits to set on the profile anonymousid string optional id # of the unidentified user, if available include it to merge a known browser session into the identified profile traits traits accepts the standard trait schema documented in the context object docid\ y31qvwxzsv3if7qtdtsgg at minimum, send email — it is the primary identifier most destinations use for matching the canonical trait names are first name and last name addresses use address1 , address2 , and zipcode ; the legacy names street , street2 , zip , and postalcode are still recognised as fallbacks but should not be used in new integrations server side traits are not optional no context is added automatically to server to server events, so an identify call is the only way traits reach a server side user profile a track event sent without a preceding identify carries no email, phone, or address, and destinations that match on those fields will be unable to resolve the user example curl x post https //production cdp ingest chord co/api/s/s2s/identify \\ h 'content type application/json' \\ h 'x write key \<server side write key>' \\ d '{ "type" "identify", "userid" "8", "traits" { "email" "customer\@example com", "phone" "+12145550100", "first name" "jane", "last name" "doe", "address" { "address1" "test ln", "city" "new york", "state" "ny", "zipcode" "10001", "country" "us" } } }' a successful call returns 200 {"ok" "ok"} a 403 means the write key is missing or invalid when to send an identify on account creation send the identify first to establish the profile, then send a user created track event to record the signup the identify makes the user addressable; the track event is what reporting counts and what downstream automation triggers on on profile changes any update to email, phone, name, or address should be forwarded so the profile stays current on first identification of a known session include anonymousid alongside userid so activity already attributed to the anonymous visitor is merged into the identified profile without it, a customer's browsing history and their orders remain two unrelated records do not call identify from a generic persistence hook backends commonly save the customer record on login, cart update, and administrative edit forwarding all of those produces a high volume of identical identify calls and constant churn on downstream profiles send an identify only when a trait you actually forward has changed ordering send the identify before any track event that depends on its traits traits are applied to the profile at ingest and are available to subsequent events — they are not applied retroactively to events that have already been processed for a server side flow that both creates a user and records the signup, that means two sequential calls post /api/s/s2s/identify → userid + traits post /api/s/s2s/track → event "user created"