Marketplace
The Marketplace is where organizations share the resources they have built and put resources built by others to work.
Browsing the Marketplace, adding a resource to your organization, publishing and pricing listings, and being paid for what you sell all depend on your organization's plan, the role permissions you have been granted, and the permissions set on the resources involved. Someone who does not have permission to add a resource can request approval from an organization admin. The access model is documented in one place: Access & Permissions.
Purpose
The Marketplace is where organizations share the resources they have built with other organizations, and use resources built by others. It turns proven, reusable work — templates, MCP Servers, guardrails, skills, tool definitions, and widgets — into something an organization can list, discover, and adopt without building it from scratch.
That makes it useful in two directions:
- If you are looking to move faster (a buyer). Instead of building every resource yourself, you can adopt work another organization has already built and proven — which shortens the distance between starting with Opal and getting real work done, and brings in capabilities your own team does not have in-house.
- If you have expertise to offer (a seller). Resources your team has already built become something other organizations can use, and something you are paid for.
It is relevant to a wide range of roles: builders who create resources, administrators who govern what enters their organization, and business owners who want to extend their team's capabilities.
This page is the map. It explains how the two sides work, points to the page that covers each part in depth, and tells you where to start.
In This Section
- Marketplace Profile — Your organization's public-facing presence on the Marketplace, and the first of the two setup steps completed before it can sell. Marketplace Profile
- Listings — The resources your organization publishes for others to adopt: which resource types are eligible, how each one is priced against a usage-based unit or offered for free, how verification works, how buyers find and adopt a listing, and what happens when you take one down. Listings
- Payouts — The second setup step, and how the money moves: buyers are charged in credits, Opal retains a 20% service fee, and the remaining 80% is paid out to the seller in US dollars. Payouts
Key Concepts
Finding and adopting a resource (the buying side). Users browse, search, and filter the Marketplace to find resources that match a need. A user with the right permission can add a resource to their organization directly; a user without that permission can request approval from an organization admin, who then approves or declines adding it. That approval step is what makes adoption deliberate: administrators keep control of what enters their environment.
Publishing a resource (the selling side). Selling follows a fixed order. An organization sets up a public-facing marketplace profile and configures its payout settings; once both are in place, it can create listings for eligible resources. Eight resource types can be listed: agent templates, task templates, flow templates, MCP Servers, tool definitions, guardrails, skills, and widgets.
Pricing follows usage. Each listing is priced against a usage-based pricing unit — per 1M output tokens for an agent template, per 1K renders for a widget, and so on. The unit is fixed by the resource type; the seller sets the price, or makes the resource free. Listings has the full table.
Credits in, dollars out. Buyers pay in credits, the balance every organization uses to fund its usage of Opal. Sellers are paid out in US dollars and Opal retains a 20% service fee on each transaction. See Credits.
Verification is the trust signal. A seller can request verification on a listing. The Opal team reviews the resource for safety and against Opal's Marketplace policies, then approves or rejects it. A verified resource carries a trust signal that helps buyers choose with confidence between listings. Verification is optional — a listing can be published without it.
Listings can be taken down. A seller can take a listing down at any time. Buyers of that resource are notified and automatically lose access as the resource is archived for them, so a takedown has a downstream effect on organizations already using it.
Templates travel well. Agent templates, task templates, and flow templates are all listable, so a blueprint proven inside one organization can be adopted by another rather than rebuilt. See Templates.
Marketplace settings sit with the organization. An organization's marketplace profile, listings, and payouts are managed together at organization level, alongside its other organization settings — which is why the selling side is usually an administrator or finance task rather than a builder one.
Short definitions of the terms used here are in one place: Glossary.
Where to Start
If you are here to adopt something, start with Listings. It covers the buying side end to end: which resource types you will find, how pricing units work, what verification means, and how to add a resource to your organization or request approval to do so. Follow it with Credits to understand the balance you will be spending.
If you are here to sell, start with Marketplace Profile, then Payouts, then Listings. That is the order the platform expects: profile and payout settings first, listings after.
If you are governing what your organization adopts, read Access & Permissions for the permissions behind approval requests, publishing, and payouts.