Should organization memberships and invitations be synced in the component?

[RobLMartin]

I'm using WorkOS AuthKit for a multi-tenant B2B app and need to track organization memberships and invitations.

Currently, the component syncs users but not memberships/invitations. I've implemented webhook handlers in my app to sync these (similar to how the component syncs users), but it seems like this could be valuable to include in the component itself since:

1. Organizations/memberships are core WorkOS AuthKit concepts
2. Most B2B apps using WorkOS will need this to support showing memberships and invitations in app with convex.
3. It follows the same pattern as user syncing

Would you be open to a PR that adds organizationMemberships and invitations tables to the component? Or is the recommendation to keep these in the parent app? Happy to provide more context or a draft implementation if helpful.

[ianmacartney]

Thanks for opening the issue. Do you imagine wanting to extend these tables at all, or just store basic metadata? It seems reasonable to sync it, but the question of what's in vs. out of the component can have implications on how tightly coupled to other data in your app is. For instance, if you want to modify or customize the way that these are tracked, then you might want your own table. Or if you want to use IDs with proper table names and ID types, then keeping them in your own tables is the best way for now. But if most people will just want the same data and the same access patterns to retrieve the data, and they are already fetching their user from the component already, then it seems reasonable to provide membership/invitations. There will be a trade-off always, and maybe the component just syncs whatever events are sent to it and is happy to only sync users but can do more if it gets those events?

…

On Thu, Mar 19, 2026 at 8:09 PM Rob ***@***.***> wrote: *RobLMartin* created an issue (get-convex/workos-authkit#32) <#32> I'm using WorkOS AuthKit for a multi-tenant B2B app and need to track organization memberships and invitations. Currently, the component syncs users but not memberships/invitations. I've implemented webhook handlers in my app to sync these (similar to how the component syncs users), but it seems like this could be valuable to include in the component itself since: 1. Organizations/memberships are core WorkOS AuthKit concepts 2. Most B2B apps using WorkOS will need this to support showing memberships and invitations in app with convex. 3. It follows the same pattern as user syncing Would you be open to a PR that adds organizationMemberships and invitations tables to the component? Or is the recommendation to keep these in the parent app? Happy to provide more context or a draft implementation if helpful. — Reply to this email directly, view it on GitHub <#32?email_source=notifications&email_token=AACZQW252PGLY6IEKSPKBJD4RSY67A5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NBRGA2TIMZVGA2DBJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACZQWZRDCYTFLK4JDPYI3T4RSY67AVCNFSM6AAAAACWYVI7L2VHI2DSMVQWIX3LMV43ASLTON2WKOZUGEYDKNBTGUYDIMA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[RobLMartin]

Thank you for getting back to me so quickly.

Yeah, those are some fair points, but it got me thinking wouldn't we always want our own table? Say I make a organization memberships and users table that updates based on the webhook. I can say the userId of the membership is a v.id("users") and get that record when I want to display an orgs members(firstname, lastname, profilepic) on some admin screen.

Today I'm not sure I can relate them with the components table, and I would have to retrieve the user via the WorkOS API, or the components workOSAuthKit.lib.getAuthUser, but I don't think I'm supposed to use it that way.

What are your thoughts on that, any suggestions?

[ianmacartney]

Yes in general I prefer to have my own users & organizations, or to relate them via IDs and do the lookups as necessary via the component (though you wouldn't want to do individual queries within a larger join for many users - would want to batch query users).
I think memberships & invitations makes sense to sync - it's well defined enough. And extra fields you could capture in your own tables and use foreign keys