Explore›For API Providers

FOR API PROVIDERS

Turn an existing API into an agent-ready revenue surface.

Mahshar gives providers an additional way to offer an existing API for discoverable, pay-per-call USDC access. Builders and autonomous agents get a clear interface for finding and purchasing calls; you keep operating the upstream service.

List Your API See the Marketplace

AN ADDITIONAL CHANNEL

Your API does not need a new business model.

Mahshar can sit alongside the way you already sell and operate your service. Existing customers can continue using your domain, subscriptions, infrastructure, and direct authentication.

For a Mahshar listing, you define a supported request contract and per-call price. Mahshar adds a distinct agent and pay-per-call path through its Marketplace architecture.

Current customersExisting subscriptionsYour API domainYour infrastructureDirect authentication

TWO CUSTOMER JOURNEYS

Traditional access and agent-ready access solve different needs.

A human-led commercial journey can support ongoing relationships and negotiated plans. A machine-led journey needs terms it can inspect and act on inside a request flow.

TRADITIONAL API ACCESSHuman or team
  1. 1Pricing page
  2. 2Signup
  3. 3Billing
  4. 4API key
  5. 5Integration
AGENT-READY MAHSHAR ACCESSBuilder or agent
  1. 1Discover
  2. 2Inspect price
  3. 3Payment requirement
  4. 4Pay
  5. 5Call
  6. 6Receive

WHY AGENTS CHANGE DISTRIBUTION

Being callable is only the beginning.

Software can choose a service while it is completing a task. For that decision to be programmatic, the service also needs to be discoverable, understandable, priced, payable, and described by a predictable request contract.

Mahshar connects those requirements through its public Marketplace and agent discovery endpoint. Its OpenAPI document describes how clients use the public machine interface.

Explore agent interfaces Read documentation
01Discoverability
02Machine-readable information
03Clear per-call pricing
04Programmable payment
05Declared request contract

THE MARKETPLACE LAYER

What Mahshar handles.

The provider continues to run the upstream service. Mahshar handles the implemented marketplace path around discovery, payment-aware access, and seller accounting.

01

Discovery

A public Marketplace and machine-readable discovery for eligible active listings, plus an OpenAPI description of Mahshar’s public machine interface.

02

Pricing

A provider-configured USDC price for each paid call.

03

Payment flow

The implemented x402 requirement, authorization, verification, and accounting path.

04

Access

Payment-aware proxy execution against the configured request contract.

05

Credential protection

Stored seller credentials are omitted from public discovery and buyer-facing listing data, then injected server-side when the configured listing requires them.

06

Earnings

Accounted paid calls feed the existing seller earnings and withdrawal interfaces.

PROVIDER CONTROL

You control the service and configure the listing.

You control the upstream API and listing configuration. Activation remains subject to Mahshar’s verification and marketplace health safeguards.

Your upstream API

The endpoint and infrastructure remain yours.

Listing status

You can activate or deactivate an eligible listing; verification and marketplace health safeguards still apply.

Price

You set the USDC price per call.

Presentation

You manage the name, description, and category.

Request contract

You configure the supported method and declared buyer inputs.

Authentication

You choose the supported public, API-key, bearer, or query-credential mode.

YOU DO NOT NEED TO UNDERSTAND X402 FIRST

You provide the API. Mahshar handles the marketplace payment layer.

Mahshar is designed to let providers list an existing API without rebuilding its own billing flow around x402. The Seller application asks for the endpoint and the listing information Mahshar actually needs, while the buyer-facing x402 exchange remains part of Mahshar’s Marketplace flow.

This is not a promise of zero configuration: the request contract, authentication mode, public metadata, and price still need to be accurate.

YOU PROVIDEAPI endpointContract · availability · direct customers
MAHSHAR PROVIDESMarketplace pathDiscovery · x402 · USDC · access

CURRENT PROVIDER FLOW

From endpoint to active listing.

The production Seller application uses a focused workspace rather than a generic submission form. Publication depends on the current endpoint and request-contract checks passing.

  1. 01

    Connect

    Connect the provider wallet used to own and manage the listing.

  2. 02

    Analyze

    Paste the public HTTPS endpoint and run the current endpoint analysis.

  3. 03

    Configure

    Review the name, category, HTTP method, authentication mode, and description.

  4. 04

    Describe the request

    Confirm body behavior and any declared path or query inputs buyers may send.

  5. 05

    Price and preview

    Set the USDC price per call and review the Marketplace presentation.

  6. 06

    Publish

    Mahshar saves the listing, rechecks the stored endpoint contract, and activates it when the checks pass.

Open Seller application Wallet connection is required in the Seller application.

WHAT HAPPENS TO MY CREDENTIALS?

Configured credentials stay out of public listing data.

Stored seller credentials are not included in public discovery or buyer-facing listing data. When required by the configured listing, Mahshar injects the credential server-side before calling the upstream API.

Read provider documentation

PROVIDER FAQ

The practical questions, answered plainly.

These answers describe Mahshar’s current production behavior. They do not promise revenue, endpoint performance, or geographic availability.

Do I need to rebuild my API?

Mahshar is designed to list an existing HTTPS API endpoint. You configure how Mahshar may call it; your direct integration and infrastructure remain separate.

Do I need to understand x402 first?

No prior x402 expertise is required to begin the provider flow. The Seller interface collects the endpoint, request contract, authentication mode, public metadata, and per-call price Mahshar needs.

Can my API use API-key or bearer authentication?

Yes. The current listing flow supports public access, an API key in the x-api-key header, bearer authentication, and a configured query credential.

Who sets the API price?

The provider sets the listing’s positive USDC price per call and can manage it through the existing listing interfaces.

Does Mahshar include my upstream credentials in listing data?

No. Stored seller credentials are not included in public discovery or buyer-facing listing data. When a configured listing requires one, Mahshar injects it server-side before calling the upstream API.

Can AI agents discover my API?

Eligible active listings can appear through Mahshar’s machine-readable agent discovery. The OpenAPI document describes how clients use Mahshar’s public machine interface.

What does the buyer pay with?

Mahshar’s current paid-call architecture uses USDC through its x402 flow on Arc Mainnet.

Which network does Mahshar use?

Mahshar’s implemented production payment contract targets Arc Mainnet.

Can I continue serving customers outside Mahshar?

Yes. Mahshar is an additional listing and access path for the configured endpoint; it does not replace your existing direct customer relationships.

How do I get started?

Open the Seller application, connect the provider wallet, paste the endpoint, and follow the analysis, configuration, pricing, and publish flow.

OFFICIAL CONTEXT

Learn about the wider agent-payment ecosystem.

Mahshar uses Circle technologies but is not presented as operated by, endorsed by, or part of Circle.

Circle Agent Marketplace Circle: What is x402?

A NEW DISTRIBUTION SURFACE

Your API already has value. Make it discoverable to the next class of customers.

List Your API Read Provider Documentation