Application Ownership Verification

[The-LukeZ]

Summary

Add API endpoints to verify if a user owns or has access to a Discord application, enabling developers to build tools that require application ownership validation.

I wanna bump this topic into existence because I'm building something that should verify ownership of an app before accessing some things.

Motivation

Currently, there is no straightforward way to verify through the Discord API whether a user owns or has access to manage a specific application. This limitation makes it difficult for:

• top.gg and other bot listing platforms to programmatically verify ownership
• Application management dashboards
• Tools that require confirming a user's relationship to an application
• Third-party services that integrate with Discord applications

Proposed Solutions

Option 1: Enhanced User Object + Team Endpoint

Add ownership information to the application object and provide a team endpoint for verification:

Changes to Application Object

{
  "id": "123456789",
  "name": "My Bot",
  "owner_id": "987654321",
  "owner_type": "user", // or "team" or an enum value indicating the owner type
  // ...
}

New Endpoint:

GET /teams/{team.id}

Returns team information including member list (array of partial user objects), allowing verification that a user is part of the team that owns an application.

Pros:

• Provides explicit ownership information
• Enables verification of team membership
• Backward compatible (new fields can be optional)

Cons:

• Requires two API calls for team-owned applications
• More complex implementation for the Discord API

Option 2: OAuth2 Applications Endpoint (Preferred)

Add a new OAuth2 endpoint that returns all applications a user has access to:

New Endpoint:

GET /users/@me/applications

Required OAuth2 Scope: applications.read (new scope) or use an existing scope

Response:

[
  {
    "id": "123456789",
    "name": "My Bot",
    "icon": "...",
    "description": "...",
    "access_type": "owner" // or "team_member"
  },
  // ... more applications
]

The applications are either an application object or partial user objects.

Pros:

• Single endpoint to verify access
• Simple implementation for developers
• Follows existing OAuth2 patterns (/@me/*)
• Can include access level (owner vs team member)

Cons:

• Requires new OAuth2 scope

Implementation Notes

• Either option should respect existing privacy settings
• Consider rate limiting similar to other user endpoints
• Both options should work with both user-owned and team-owned applications

Alternative Considerations

If both options are feasible, implementing Option 2 would be the most developer-friendly solution, while Option 1 could be added later for more granular team management features.

References

• Similar functionality exists in other platforms (GitHub Apps, Google Cloud, etc.)
• @AEnterprise meant that it's been suggested for a very long time