identify, but a reward under the account id did not credit the decision made under the anonymous id, or the dashboard still shows two users.
The call was refused
A publishable key cannot identify: the browser never holds the authority to merge identities. The response is a403. Call identify from your server with a secret key. See Identify users.
The ids are swapped
anonymous_id is the id you decided with before the person was known; user_id is the account they turned out to be. Swapping them links the account into the anonymous id. Check the request against the decision’s user_id.
The decision raced the link
identify is an ordered mutation. A decide sent before the identify response arrived may have been selected against the unmerged profile, and in rare cases is answered 409 with Identity changed during selection; retry the request. Await identify before the next decide that should see the merged profile; the server SDK never queues it behind events.
The link conflicts
A409 with Identity conflicts with an existing user means the anonymous id is already linked to a different account. The usual cause is reusing an anonymous id after logout. Mint a fresh anonymous id on logout. See The API returns 409 conflict.
The environments differ
A decision under a test key and anidentify under a live key concern different users: identity is scoped to the environment. Use the same environment end to end.
What merging does and does not do
After a successful link, decisions and events on either id attribute to the same person, and the merged user carries theidentifiers and attributes you sent. The link is durable and a repeat is a no-op. It does not rename anything in your own systems: keep sending the account’s user_id from then on.