API Feature Request: Track invite used.

[LaxSlash]

Feature request to include the invite code used as well as the inviting member in the member join event. Alternatively, include invite used information in the member object (invited-by: [USER SNOWFLAKE]).

[jhgg]

Hi,

What's the use case here?

[erkinalp]

@jhgg I think this could easily be solved by user-specific invites.

[Vexs]

Handy for bot-logging, so you can tell what invite is being used for raids, or if unsavory people are joining, you can find out how. Currently can be done by polling the invite list for increments, but thats unreliable at times.

Similar vein, a create invite event would be nice.

[MinnDevelopment]

There is an OAuth scope which allows applications to add users to guilds. This could be used instead.

[erkinalp]

That has different semantics though. Does not replace mass invite use tracking, and also cannot be satisfied by user-specific invites.

[MinnDevelopment]

This conversation ended 3 years ago, please stop necroposting.

[boatcoder]

Considering it's never been addressed how can it be necroposting.

[cryptiklemur]

Not really the same use case that vexs pointed out

[s5bug]

@MinnDevelopment vexs means that when a user joins, the invite information would be sent in an event. Not add a user to a guild using an invite.

[MinnDevelopment]

He is talking about adding this for raid prevention, I'm just saying that this OAuth scope already makes this possible as it gives full control over who gets added in the first place making this information available.

[cryptiklemur]

OAuth scope doesn't let people create invite links for others to join. It also means you lose the discord.gg link.

[Mheetu]

+1 Would be helpful to find out who keeps inviting ban evaders/troublemakers.

On a side note, I'd also like to see this information in the user's profile within the client. An admin shouldn't have to write a bot to figure it out.

I'd honestly like to see the HTTP REFERRER header information too if it was defined when the user joined through discord.gg... though I can imagine that may raise some privacy issues, inconsistent data, or even spoofed data. But it'd still help to know where users are posting invites to your server.

I don't see OAuth as a viable solution to this, it's more of an inconvenient workaround for those who don't don't require that flow.

[Cynosphere]

A current way to do this is to be able to check the invites that exist at the current point in time, store them yourself, then on member join, check which invite count updated that way. I don't know if this is possible but it should be as long as the bot has perms to make invites I think.

[eritbh]

@BoxOfFlex I feel like there would be some edge cases with that method, for example when two invites are used by two different users at once. You might also have to handle single-use invites differently. Not impossible to implement, but not perfect either.

[Seklfreak]

Another issue of polling the existing invites are that vanity invites for partners are not listed in the server invites.

Including the used invite in the member join event would provide a much cleaner way to track invites. It would also reduce the HTTP API traffic as you don't have to request all server invites for every member joining a server.

[eritbh]

Now that I think about it, that would actually be a massive pain to implement... You'd have to also watch for when invites are invalidated to make sure your cache stays up-to-date so users don't get associated with two invites. And yeah, even that's assuming that you don't have a vanity link, that would mess everything up.

[CEbbinghaus]

this would make referring easier for bot programmers. im currently working on a system where people invite multiple friends and get a role as a reward. this would make my life a lot easier

[danbopes]

Right now, my use case is this: A user joins the server. I'd like to detect if the invite link used was temporary or permanent, and if a permanent one, then shoot a DM to the person explaining how to use the bots within discord.

[iiAbady]

You can just track the invites, and see which one of them increases when a guild event happen. but this request will make every thing easy

[demirtasdurmus]

Thanks.
For now, I solved the issue by setting tha max use limit to 2 for uniqe links and deleting after it is used once. Not the best solution but gets the job done.👌

[JDJGInc]

If track invite is not an idea for staff, why can't it just be a special intent?
And then a team could keep on eye on the bot?

[jpollard-cs]

for what it's worth you can generate your own invite codes and require these to be entered in a special channel before your bot gives them access to the rest of the guild, but not sure if this is against the Discord ToS 🤷

[RealAlphabet]

Dec 10, 2017, Feature Request
Tagged planned with description We are going to fix this pretty soon.
Jan 19, 2023, 5 years later...

[UP929312]

Yes, this is possible through tracking the guild's invite list, but if discord already knows which invite was used, why not just send that along too?

[NathanNull]

Heyyyyy guys, this feature seems really useful, maybe add it at some point?

[Phoenix616]

Now that this is exposed to server admins via the member list in the client it feels right to also expose this in the API (or document it because I've heard it already is exposed 👀)

[seailz]

What endpoint exposes it?

[Jupith]

It's not

[ooliver1]

It is. In the beta "Members" tab for moderators in some servers. you've got to be clear on what you're denying

[advaith1]

bots cannot access the endpoint that the client uses for that data

[NoobyT]

Now it's on the Members tabs, it should definitely be made available via the API. I have been waiting for 2 years at this point.

[hackermondev]

Bots can now access the source_invite_code through the new elasticsearch member search endpoint /guilds/:id/members-search endpoint (the experiment is still rolling out to servers though fully rolled out).

[RealAlphabet]

Return 403 for me.

[shotaxx]

i cannot find a reference on postman for further details. could that also get added or did i just miss it?

[refat2090]

@hackermondev I don't think this endpoint provide the source_invite_code data now.
( (It had worked a week ago but even today it is not providing the source code) can you please confirm if this is the case form your side?

[refat2090]

@Haptein , can you please provide a screenshot of the API call and the url that you are using?

[refat2090]

@Haptein , I am still unable to recreate it.

[LawMixer]

This works for me, POST /guilds/:id/members-search with your discord bot token. Could we see something in the websockets for on member join?

[FinlayDaG33k]

Doesn't seem to work with bot token anymore unless there is a specific thing you need.
Does work when I use the token of a regular user account.

[Red-K0]

A POST works, but is there any way or query to add to have it return more than the first 25 members? Requests from the members tab only use the ?limit query, but modifying that does nothing in a manual request.

[shotaxx]

for me it worked setting the limit to 999

[kohlerpop1]

Even after setting the limit to 999, it still only returns the most recent 25 joined members. Any other ideas?

[hackermondev]

Limit is sent through request body not query in the new endpoint.

[kohlerpop1]

Much appreciated sir!

[shotaxx]

Thanks for this!
I use this new feature to auto apply roles to newly joined members based on the invite used. The API has some significant delay until it updates the memberlist with the new member. From my experience it takes up to 2minutes. You have to take that into account in your code.

[LawMixer]

Hey, thanks for this amazing feature! I've already been trying to implement it.

Do we know when this will be fully documented and rolled out (in an announcement) yet?

[LawMixer]

I know - rolling out has been released (or is close it it) judging on if everybody gets it, though it is not yet documented.

[yosbergc]

Definitely this is necessary

[deviouscomputer]

Has there been any progress on implementing this permanently?

Per earlier conversation in this, source_invite_code appears to have been temporarily added and subsequently removed.

[Droid00000]

They didn’t want to document the endpoint that returned this data. See #7068

[benbarbersmith]

This would be hugely useful for bots my company builds and maintains.

Workarounds caching invite usage counts (as mentioned above) might be acceptable for small private servers, but they fail on public or larger servers for a variety of reasons. For example:

• Vanity URLs do not expose usage counts
• Users joining via Discovery will disrupt/invalidate counts
• During periods of frequent joins (when e.g. 10 users per second are joining), accurate tracking becomes impossible as API latency is longer than the average period between joins

Adding the source to members as part of the API would allow for a richer understanding of how user behavior varies by join source, better raid detection, spam flagging, etc.

[AlmostSuspense]

usage count of the vanity is exposed using the get guild vanity endpoint