15.2 GitHub Marketplace

Why Marketplace is on GH-900

Domain 7 asks you to describe the GitHub Marketplace and its purpose. The skill is consumer-facing, not "build a billed app from scratch." You need to know that Marketplace is how people discover tools that extend GitHub, that the two headline listing types are GitHub Actions and Apps, that you install GitHub Apps on a user or organization account, and that GitHub Apps are not OAuth apps.

GitHub Marketplace lives at github.com/marketplace. In the web UI you can also open the global navigation menu and choose Marketplace. The catalog is public. It is not an InnerSource portal, not the GitHub Enterprise Server license store, and not a replacement for GitHub Actions. Actions still run as workflows in .github/workflows; Marketplace is one place to find reusable actions and apps that plug into GitHub.

GitHub's publisher docs state the purpose in one sentence: Marketplace connects you to developers who want to extend and improve their GitHub workflows. You can list free and paid tools. GH-900 will not ask you to recite the Marketplace Developer Agreement. It will ask whether a CI linter, a project board sync, or a Slack notifier is something you find on Marketplace, and what happens when you install it.

Two listing types: Actions and Apps

Marketplace offers developers two types of tools: GitHub Actions and Apps, and each type has different listing rules.

GitHub Actions on Marketplace are reusable automation units you call from a workflow with uses: owner/repo@ref. Anyone can publish an action if the repository is public, contains a single action metadata file (action.yml or action.yaml) at the repository root, and uses a unique name. GitHub publishes qualifying actions when you cut a release; they are not reviewed by GitHub the way paid apps are, as long as those requirements are met. Publishing a release to Marketplace requires two-factor authentication. GitHub verifies some partner organizations, and those publishers show a verified creator badge. That badge is not the same as the verified badge on an organization's GitHub profile.

You do not "install" an Action onto your user account the way you install a GitHub App. You add it to a workflow. The action runs with the permissions of that workflow job, on a runner, in repositories you already control. If an exam stem says "install this linter so every repository in the org automatically has it," that is an app installation or an org-wide workflow policy question—not starring an action listing.

Apps on Marketplace include GitHub Apps and OAuth apps. Anyone can share an app for free. Only apps owned by organizations can sell paid plans. To publish paid plans and display a marketplace badge, the organization must complete publisher verification. Each paid app also goes through financial onboarding so GitHub can bill. You can offer up to 10 pricing plans on an app listing. Paid personal installs bill on the personal account's current billing date with the payment method on file. A paid plan with a free trial is a 14-day trial; cancel during the trial to avoid charges, or the paid subscription starts when the trial ends.

Developers can also share a public GitHub App with a direct link even if it is not in Marketplace. Marketplace is the discovery catalog, not the only distribution path.

Installing a GitHub App

A GitHub App is a tool that extends GitHub. GitHub's examples include opening issues, commenting on pull requests, managing projects, and posting to Slack when an issue opens. To use the app on your resources you install it on your user account or organization account. You can install the same app on multiple accounts—for example your personal account and two organizations you own. GitHub documents no limit on how many apps you can install.

Installation is a permissions conversation:

1. Open Marketplace, open the app, choose a pricing plan, and begin installation.
2. Confirm the account (personal or a specific organization).
3. GitHub shows the permissions the app requested—read metadata, write issues, and so on. You must be comfortable granting them and you must trust the app developer.
4. If the app requests repository permissions, choose All repositories or Only select repositories. If you choose selected repositories, you name each one. If the app creates repositories, GitHub grants it access to those new repositories automatically.
5. Complete the order and click Install.

Organization installs are restricted. You must be an organization owner or have admin permissions on a repository to install a GitHub App on an organization. If the app also needs organization permissions, an organization owner must approve. That is why "any org member can install any Marketplace app on the company" is a trap.

Installation is not authorization. Installing grants the app access to the organization and repository resources it requested, for the repositories you selected. Authorizing grants the app access to your user account based on account permissions (for example read email, write gists) and lets it act on your behalf. You can install without authorizing, and you can authorize without installing. When the app acts on your behalf, it can only reach resources you can reach, and only if the app is installed on the account that owns those resources with the right permissions.

Apps sometimes request updated permissions. GitHub notifies you; the app keeps working for those new permissions only after you review and approve. If you stop using an app, suspend or uninstall it and revoke authorization so leftover tokens do not keep acting.

GitHub Apps versus OAuth apps

GitHub still supports OAuth apps. Both GitHub Apps and OAuth apps can use OAuth 2.0. The product difference is what GH-900 tests.

Unlike GitHub Apps, you do not install an OAuth app and you do not control which repositories it can access. You authorize it, and it acts as you with scopes. An authorized OAuth app can see the repositories the authorizing user can see. GitHub Apps, by contrast, are installed, use fine-grained permissions (issues without full repo contents, for example), and let the installer choose repositories.

GitHub Apps can act independently of a user with an installation access token. That token identifies a bot account such as @jenkins[bot], currently expires after one hour, and keeps working even if the person who installed the app leaves the organization. They can also act on behalf of a user with a user access token. OAuth apps can only act on behalf of a user. That is why a CI bot that must comment on pull requests at 2 a.m. is a GitHub App problem, not an OAuth app problem.

GitHub recommends GitHub Apps for new integrations because they use fine-grained permissions, repository choice, and short-lived tokens, which limits damage if credentials leak. You can still list both OAuth apps and GitHub Apps on Marketplace. One advanced exception, usually beyond GH-900 but useful as a trap: if an integration must access enterprise-level resources such as the enterprise object itself, GitHub still points people at OAuth apps because a GitHub App cannot yet be given enterprise-object permissions. GitHub Apps can still access enterprise-owned organization and repository resources.

GitHub Apps versus OAuth apps at a glance

GitHub Apps also get a single centralized webhook for events across repositories they can access. OAuth apps typically create webhooks per repository. Rate limits for GitHub Apps scale with repositories and users; OAuth apps generally use the user's limit. Those details support the same exam idea: Apps are the modern, narrower, installable integration.

Exam scenarios

A team wants a Slack bot that comments when issues open, even at night and even if the engineer who set it up leaves. They install a GitHub App from Marketplace on the organization, grant issues permission, and select the product repositories. The app acts as a bot. An OAuth app that the engineer authorized would act as that engineer and would lose access if they left.

A student finds a Marketplace Action that runs markdown lint. They do not install it on their user account. They add a workflow step that uses the action's repository and version. The Action listing's verified creator badge tells them GitHub verified the partner organization, not that GitHub reviewed every line of the action.

An org owner refuses a Marketplace install request because the app asked to write repository contents for every repo. That is the model working: installation is a permissions and repository-scope decision, not a silent OAuth repo grant.

Traps GH-900 will set

• Marketplace is a catalog, not GitHub. Buying Pro, enabling Copilot, or licensing Enterprise Server is not what Marketplace is for.
• Actions are reused; Apps are installed. Do not say you install an Action on an account. Do not say a GitHub App is only a workflow uses: line.
• Install versus authorize. Install selects org/repo resources. Authorize lets the app act as you on account-level resources.
• OAuth apps have no repository picker. If the stem says "choose which repositories the integration may access," that is a GitHub App installation, not an OAuth authorization.
• Paid apps need an organization publisher. A personal account can list a free app; selling requires an organization plus publisher verification.
• Trust and uninstall. If you no longer use the app, suspend or uninstall and revoke authorization. Leaving a forgotten OAuth grant is worse than leaving a narrowly installed App, but both are leftover access.
• Verified creator is not a security scan of the code. It marks partner publishers for Actions.

If you remember only one sentence: Marketplace is where you discover Apps and Actions; you install GitHub Apps with granular repo permissions, and GitHub recommends Apps over OAuth apps for new integrations.