Before looking at how listings, pricing, or verification work, it helps to be precise about what actually lives in this “marketplace” and who it is for.

A single storefront for two different kinds of tool

The GitHub Marketplace is GitHub’s built-in storefront where developers and organizations can find, install, and — where applicable — pay for tools that extend how they use GitHub. It offers exactly two categories of listing: GitHub Actions, small reusable automation steps that plug into a repository’s workflows, and Apps (which includes both GitHub Apps and, historically, OAuth apps), which are fuller integrations that can connect to a repository or organization and interact with it through the GitHub API.

You may likeWhat Is Git Bisect?→

Who publishes to it, and who uses it

Anyone with a GitHub account can publish an Action to the Marketplace for free. Apps can be shared for free by anyone as well, but only apps owned by an organization — not a personal account — are allowed to charge money for them. On the consuming side, any developer browsing the Marketplace can search, filter by category, read a listing’s description and reviews, and install what they need directly into their own repositories or organizations.

The Marketplace exists to solve two very different problems at once — one for the developers who build tools, and one for the developers who need them.

For the developer who needs a tool

Instead of reading blog posts to find a security scanner, a deployment helper, or a project-management integration, a developer can search one catalog, compare options side by side, and install the winner directly — no separate account to create, no invoice to chase down, no code to copy and paste from a random repository of uncertain quality.

For the developer who builds a tool

Building a great Action or App is only half the work of turning it into something other people actually use — distribution and, for paid tools, billing are usually the other half. The Marketplace removes both burdens: listings are searchable by the exact audience most likely to want them, and GitHub’s own billing infrastructure handles subscriptions, invoices, and payment methods so the publisher never has to build a checkout page.

Zooming out, the Marketplace is best understood as four connected layers, each solving a different part of “publish, discover, install, get paid.”

flowchart LR
    A[Developer builds an Action or App] --> B[Submit listing for review]
    B --> C{Requirements met?}
    C -->|Yes| D[Listing published to Marketplace catalog]
    C -->|No| B
    D --> E[Buyer discovers & installs]
    D --> F{Paid plan?}
    F -->|Yes| G[GitHub Marketplace billing API]
    F -->|No| E
    G --> H[Publisher receives purchase/cancel webhook events]
        

Two very different technical shapes behind one storefront

An Action is fundamentally a packaged, reusable workflow step, usually distributed as source code in a public repository that a workflow file simply references by name and version. An App, by contrast, is a running integration with its own webhook subscriptions, its own permission scopes, and often its own backend service that GitHub notifies whenever relevant events happen. The Marketplace deliberately unifies discovery for both, even though what happens after “install” is architecturally quite different underneath.

Choosing which category to publish under — or, as a buyer, which category to reach for — comes down to understanding what each one is actually built to do.

GitHub Apps vs OAuth apps, briefly

Within the “Apps” category, GitHub itself recommends building GitHub Apps over the older OAuth app model, because GitHub Apps offer far more granular, fine-grained permissions — an app can request access only to the specific resources it actually needs, rather than broader account-level scopes. Both can technically be listed in the Marketplace, but new integrations are steered strongly toward the GitHub App model.

Of the two listing types, publishing an Action is the more lightweight path, which is part of why so many exist.

Publishing an App is a heavier process than publishing an Action, largely because an App can touch far more of a user’s data and, potentially, their money.

In a catalog anyone can publish to, trust signals matter enormously — and GitHub gates the most valuable ones behind an explicit process rather than handing them out automatically.

These layered requirements exist because the Marketplace’s usefulness depends entirely on buyers being able to trust what they see. A badge that anyone could obtain for free would be worthless as a signal; requiring identity verification and, for paid apps, a demonstrated user base keeps the signal meaningful.

One of the Marketplace’s most distinctive features is that it acts as its own payment processor, meaning a publisher never has to build a checkout flow.

You may likeWhat Is a Reusable Workflow?→

Free trials

Any paid plan can optionally include a free trial, typically 14 days long, letting a buyer evaluate the paid tier before committing. A customer can only start one free trial per Marketplace product, preventing the obvious abuse of repeatedly resetting a trial period.

Why publishers still have to write some code

GitHub’s billing API removes the need to build payment infrastructure, but it does not remove all integration work. Every listing — free or paid — must handle Marketplace purchase events (new purchases and cancellations at minimum), and paid listings must additionally handle upgrades, downgrades, and free-trial events, so the publisher’s own system always reflects a customer’s current entitlement correctly.

A catalog with thousands of entries is only useful if the right entry is easy to find, so discovery mechanics matter as much as the listings themselves.

Because installing an Action or App can mean handing a third party access to source code, secrets, or an entire organization, security sits at the center of how the Marketplace is designed.

Actions run with the permissions you grant them

When a workflow uses a third-party Action, that Action’s code runs inside the workflow with whatever permissions and secrets the workflow itself has access to. Because Actions are not automatically verified or scanned for safety just by being listed, treating an Action’s source and reputation with the same scrutiny as any other third-party dependency is essential.

Apps request explicit, scoped permissions

GitHub Apps must declare exactly which permissions they need — read access to issues, write access to pull requests, and so on — and a user or organization must explicitly approve that scope before installation completes. This is a large part of why GitHub steers publishers toward GitHub Apps over the broader, coarser-grained OAuth app model.

Security best practices for publishers

GitHub publishes dedicated security best-practice guidance for anyone building an app intended for the Marketplace, covering topics like storing credentials safely, validating webhook payloads, and minimizing requested permissions to only what the app genuinely needs to function.

Weighing both sides — as a buyer and as a publisher — clarifies when the Marketplace is the right path and where its limits show up.

Most friction — on both the buying and publishing side — comes down to a short list of predictable pitfalls.

Seeing where the Marketplace shows up in everyday engineering work makes its abstract structure concrete.

No. It is reachable at github.com/marketplace and uses the same GitHub account, permissions, and payment method you already have.

Not directly. Only apps owned by an organization can offer paid plans, so a personal-account app must first be transferred to an organization before it can be sold.

No. Free listings only need to meet the general listing requirements. Verification is required specifically to offer paid plans.

Verified creator is a badge GitHub grants to select partner organizations for Actions specifically. Verified publisher is the broader identity-verification process an organization completes to unlock paid app plans and a marketplace badge.

Up to ten different pricing plans, which can mix free, flat-rate, and per-unit options to serve different customer needs.

No. GitHub’s own billing infrastructure processes purchases, upgrades, downgrades, and cancellations. You do need to handle the corresponding webhook events so your own system stays in sync with each customer’s current plan.

The GitHub Marketplace is a single, built-in storefront for two distinct kinds of tool — reusable Actions that plug into a workflow, and fuller Apps that integrate with a repository or organization directly — letting developers discover and install what they need without leaving GitHub, and letting publishers reach that same audience without building their own distribution or billing infrastructure. Free listings only need to meet general requirements, while selling a paid plan requires an organization to become a verified publisher, clear minimum usage thresholds, and integrate with GitHub’s Marketplace billing events. The result is a catalog that has grown to thousands of Actions and a healthy ecosystem of paid Apps, precisely because it removes friction on both the buying and the building side at once.