Using an ObjectId as the User Id Field

When setting up Cutom User Data, according to the documentation the User Id Field in the user’s custom data document must be of type string.

I’m just wondering why this cannot be an ObjectId instead or if there is anyway for it to be an ObjectId? If the app services backend can’t handle an ObjectId for some reason, then it would be good if we could enter something like "%oidToString": "_id" as the User Id Field for example.

The reason I ask is because the custom user data document already contains an _id field that can easily be used as the user’s id if it is set at creation. This then prevents having to store a second id for the user. The documentation makes it clear to keep the custom user data document as small as possible as it is encoded into the access token. However, forcing a separate string id causes the document to be bigger than it needs to be.

For example, instead of this:

{
  "_id": { "$oid": "63ed2e4fb7f367c92578e526" },
  "user_id": "63ed2dbe5960df2af7fd216e",
  "name": "Fred"
}

We could just have this (almost have the size):

{
  "_id": { "$oid": "63ed2dbe5960df2af7fd216e" },
  "name": "Fred"
}

Hello! As of our most recent release on July 26 2023, we now support both string and ObjectID types in the User ID field in custom user data documents. We’re working to update our documentation at the moment but we do support the functionality you mentioned in your example.

Ah yes so it does now. It did not work for me at first, but after trying again now, it appears to be working.

1 Like

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.