Looking for Vue jobs? Want to learn eCommerce from an established player in the space? Check out our new job board partner Adore Beauty: they’re looking for a UI Engineer Team Lead (React Native, Vue)!

This week we’ve started adding features to our new project: the Mongoose Pro subscription. The first step is how we handle prioritizing sponsor issues. In order to identify which issues are from sponsors, we’re adding a “Priority” label.

When you’re building a GitHub integration, the first question is whether you need a GitHub App, a GitHub OAuth App, both, or neither. For read-only GitHub integrations, you don’t need an app at all, GitHub makes it fairly simple to add webhooks to an individual repo with no app setup at all.

In my experience, the hardest part of working with the GitHub API is figuring out how to get permission to do what you’re trying to do. In an ideal world, we’d build GitHub Apps for integrations, because GitHub Apps are separate users that act on their own. On the other hand, OAuth Apps and apps using access tokens take action on behalf of human users.

If Netlify were an OAuth App, this comment would appear to be from a real non-bot user.

However, GitHub Apps have an unfortunate limitation: there’s no way to install a GitHub App on an individual repo. You must install Apps on an organization level. This presents a major problem for Mongoose: we’re part of the Automattic GitHub org, but don’t have access to the org.

So, instead of creating a new GitHub App and requesting Automattic install it, or creating an OAuth App, we decided to go with the low-tech personal access token approach. Personal access tokens are the easiest to work with in terms of permissions, because they have a configurable subset of the permissions the user does. But the big downside is that actions appear to be taken by the human user, rather than a bot.

Not ideal because of the human user, but it at least makes sure the “Priority” label gets added. We’re going to register a separate GitHub user with more limited permissions to make it so the label doesn’t look like it was added manually. The code that does this is open source and available on GitHub.

For adding a label to a GitHub issue, we don’t necessarily need a GitHub App. However, there is a case where we’re likely to need one: if one of the subscribers is an organization, we need to extend priority support to all members of the organization. And GitHub organization memberships can be private.

So we may end up needing to create a GitHub App that we ask subscribers to install, to get access to their membership list. But at least we don’t need a GitHub App to modify comments.

What do you think of the beginnings of our GitHub integration? Any suggestions? Feel free to respond, or post on GitHub.