Rudderstack not receiving user id in payload

Rudderstack is not receiving the feathery user id in the payload anymore. In the rudderstack live events view, they are reporting this as empty:

"userId": ""

Shouldn’t the user id always be populated in this case when it’s provided by us in the initialization? We expected it either at the top level within userId or as part of the properties.

The way rudderstack works, it should probably be in both as a track call that’s missing user id means something is probably missing in the invocation.

Separately: I swear this was something that was previously sent. So was this changed? If so, it’s a pretty big change.

We don’t call identify in rudderstack. would you prefer that we do, with the feathery user id?

According to their docs you should be able to just pass in userId with the track call?

This is likely the simplest thing across all your events I think. Not sure if an identify call is truly needed.

2.0.182 will now call identify with the feathery user id

hey peter! we’re seeing the userId come in now, but it doesnt seem to match right. ex

{
    ...
    "properties": {
        ...
    },
     ...
    "userId": "faa05b53-7d36-4ff6-ac9d-c1b0ba3663fc"
}

was the hook that came in for my user with the feathery user ID of 13648

@peter That suspiciously looks like an auto generated GUID for the user ID either by feathery or via rudderstack.

I think using identify here is the wrong call as a replacement for the user ID for the track call. Even with the identify call, i believe you need to provide the correct user ID in with the track call/

At what point in your flow are you initializing your custom user id? Do you pass it into the init() call? And are you preloading your forms at all? (if you don’t know what i’m referring to by preload, you’re probably not)

we init the form with a user-specific SDK key Feathery.init(userSdkKey). And no we’re not preloading

Ah thanks, that’s helpful. Think we fixed the issue in 2.0.186 if you can try again

1 Like