Bulk fetching targeted/specific users

[Dubz]

I am in need of an API to acquire specific users in a guild. Right now, the best approach is to fetch all users, however with guilds over 1k, this requires pagination and weighing which route is better.

I'd imagine this would still be restricted by privileged intents, if anything based on the count requested (i.e. <=5 fine, >5 required).

Example:

Say I need 7 specific users in a guild that has 8315 users. That's either 7 individually targeted user calls, or up to 9 pagination API calls (could stop early once all targets are found). Obviously I'd weigh counts and go with the less option, but if I could bring that down to 1 and specify those 7 specific users, that'd be much more useful for me.

Benefits:

• Less repeat API calls needed, guaranteed data acquisition, less overall processing time.
• Less traffic for transmit.
• Increased privacy for users not needed for processing.

My Requirements:

The only data I would need from these users, for my implementation (at this time), is their roles. This is used to calculate whether they can execute specific slash commands (end goal). While an API to calculate this and return the overall true/false would likely be easier for me, I'm sure it adds a lot more complexity to implement on Discord, and a lot less likely to be used by others. I'd be happy to leverage it as an alternative though. I'm sure I'm not the only one who would benefit from this targeted users feature.

For reference, a "get members with role" would not help for my case. I know it doesn't exist, but in case it was thought of.

[vakiliner]

Have you tried Request Guild Members with the user_ids parameter?

[Dubz]

Have you tried Request Guild Members with the user_ids parameter?

Can't use this as I am not operating a gateway bot. This is a webhook/slash command bot. This feature doesn't exist for those, however it's similar to what I'm looking for (although it states it will keep sending events until you get the ones you're looking for, essentially pagination like I mentioned, so not really any different). I can make do with a 100 user/request limit, the most I'd ever potentially need is 249. 3 calls is definitely better than 20+ (assuming the guild is over 20k users and I need to target a set of, say 45). I know this would be a small number of cases as most guilds are under 1k users, but still need to plan ahead. Would be cool if it could go higher with the privileged intent, but the number of times this will be the case are likely to be a fraction of a percent. Moreso just to have a "guaranteed" method than weighted routes.

If I were using a gateway bot, the role events would be a better route for me to take actions as needed.

[advaith1]

Where are you getting the user ids from? if the users are being provided in an interaction then Discord automatically resolves all of them for you.

[Dubz]

IDs are cached as part of the bot's main feature.
For reference, if interested: https://cloudia.bot/

Basic flow is:
Guild admins add bot and configure who can use command
Command is used to create role, user of command is listed as the role "owner" (hence the max being 248* users: 250 roles, minus the bot's and Nitro Booster as they're integrations and unable to be "custom managed roles" given out, leaves up to 248 potentially unique owners).
Said "owner" may want to "transfer" the role to a different target user. That's good and resolves as mentioned when used in the command, so it can check immediately whether or not the target user is allowed to create said role. If they aren't, the transfer is blocked (to prevent abuse, so users with permission can't make them on behalf of others and just transfer them to keep).

The part where this ask comes into play is the passive cron checking (ex. weekly) to ensure the users maintain access to said role creation ability (i.e. slash command). If they lose access, they should lose their custom role. Of course all of the "when/who/how/etc." will be further configurable (ex. give them a 3-day notice before deleting, or delete immediately). For small guilds (5-100 users likely average range), getting all users will suffice. However bigger guilds that might leverage this at a higher scale can increase the number of API call requirements to gather the information to check over all of them. For a couple guilds, no problem. At large bot scale, it could take weeks to get through all of the guilds/role owners.

This has been asked by several of our users already. Others left to find one that does this for them (including self hosted options). While I can very easily implement this today at the scale I'm running at (~275 guilds), that number is growing fast (it was at 100 two weeks ago) and I know I'll hit rate limits very quickly as a result. The last thing I want to do is to set it up for failure and take away features due to rate limits, so i just haven't offered it yet.

[advaith1]

I see.

If your bot has the Guild Members intent and it has a moderation permission in the guild (manage guild, manage roles, manage nicknames, kick, ban, timeout) then one option you have is using the undocumented members-search endpoint:

POST https://discord.com/api/v10/guilds/:id/members-search

{
    "and_query": {
        "user_id": {
            "or_query": [
                "USERID1",
                "USERID2"
            ]
        }
    }
}

but note that this is not yet officially supoorted and may change in the future.

If that is not the case, your only option is using the gateway as vakiliner suggested. though we may add a http endpoint providing that gateway functionality in the future.

[Dubz]

I'm currently still pending approval for said intent. It was denied as they considered it not needed for the former action I described, despite adding the latter action where it actually needs it. I'm assuming it was half read and denied from that, so hopefully they re-check it and it gets approved.

I definitely have "Manage Roles" since it's a bit required for this bot (and enforced to use since it's kinda useless without). I did see the search API too, but didn't know it included IDs. I figured usernames, messages, etc. if anything. I'll have to keep this in mind and poke around at it, but like you said it's not officially supported and could change, so I don't want to build up a dependency on something in that state.

Hopefully the broader targeted user acquisition could be added if anything. I would think it's something simple-ish to add on with the other components (essentially the same as the one user, but with a list/loop). Look forward to either, though!

Thanks for the information, appreciate it!

Also huge thanks for this update the other day. I looked high and low for an option a few months ago and gave up. Just recently stumbled across it, exactly what I needed! Brought me back here to ask about this portion as well since it seems to be the only piece left my bot would benefit greatly from being able to utilize.