Marketplace Distribution (for APIs)

Marketplace-first distribution is the strategic choice to ship an API through an existing marketplace (RapidAPI, Apify, MCPize, MCP directories) as the v1 channel — letting the marketplace handle billing, API keys, metering, payouts, and discovery — instead of building your own auth + Stripe + customer-acquisition stack on day one.

This is the load-bearing decision behind the mini-apps/overview|mini-apps series.

What the marketplace gives you

Concern	Marketplace handles
Customer auth	API key issuance, header forwarding
Billing	Plan tiers, metering, monthly invoicing, refunds
Payouts	Monthly transfer to your bank, tax forms
Discovery	Search, category pages, recommendation, badges
Trust	Customers already have an account; no fresh KYC against you
Docs hosting	OpenAPI import → auto-generated docs + code samples in 6 languages
Rate limiting	Per-plan caps enforced upstream of your service

What you keep:

The service itself (your code, your infra, your IP)
A proxy-secret header (e.g. X-RapidAPI-Proxy-Secret) that proves the request came from the marketplace, not direct
Total control over pricing tiers (you set them; marketplace just enforces)
The right to also sell direct later

The proxy-secret pattern

The marketplace puts itself between users and you:

Customer ──→ marketplace gateway ──→ your service
                                   ↑
              X-RapidAPI-Proxy-Secret: <your secret>
              X-RapidAPI-User: <customer key>
              X-RapidAPI-Subscription: <plan>

Your service does one check at the edge: is the proxy-secret header the shared value we configured at listing time? If yes → marketplace request, proceed. If no → 401, optionally fall through to direct-customer auth (later).

This is the entire auth layer for v1. ~20 lines of middleware.

Why this beats building it yourself for v1

You build it	Marketplace does it
Stripe integration (2–3 days)	Already done
Customer dashboard (1 week)	Already done
Cold-outreach for first customers	Marketplace listing surfaces you
Trust ladder (“who is this random API”)	Marketplace’s trust transfers
Tax handling per jurisdiction	Marketplace remits
Card declines / dunning	Marketplace handles
30% revenue share	(the cost)

The 30% revenue share is the price of skipping ~3 weeks of work and ~6 months of cold-outreach growth. For a weekend product that may not pan out, this is the correct tradeoff. Move to direct billing after you have signal that the product is worth that work.

When it works

API with per-call pricing (not per-seat, not flat monthly with seats)
Stateless or near-stateless service (you don’t need to know who the customer is across requests — the proxy header tells you the plan and a stable key per customer is enough for rate limiting)
Evergreen demand (people will keep needing it — utility APIs, content conversion, data lookup)
Category already exists on the marketplace (you have references for pricing, feature parity)

When it doesn’t

B2B with annual contracts and procurement (marketplaces are self-serve)
Stateful multi-tenant SaaS (dashboards, accounts, integrations)
Anything requiring direct customer support relationships
Anything with privileged data access (HIPAA, financial regulated, etc.)

The “marketplace → direct → premium” ladder

A common path for products that work:

v1: marketplace only. Discovery + billing + first revenue. You learn what tiers customers actually buy and which endpoints they hit.
v2: direct + marketplace. Add your own Stripe + /dashboard. Marketplace stays for discovery; direct is for higher margins and customer relationships. Upsell heavy marketplace users to direct (“save 20% + dedicated support”).
v3: enterprise. Annual contracts, SLAs, dedicated rate limits. Now you’re a real business.

For mini-apps/overview, every product starts at step 1. Most stay there. The few that prove out graduate to step 2.

Pricing pattern (from BACKLOG.md research)

Three tiers + a free tier seems to be the convergent shape on RapidAPI:

Tier	Calls/mo	Price
Free hook	~50	$0
Basic	~1,000	~$9
Pro	~10,000	~$29
Ultra	~50,000	~$79

Adjust by checking 3–5 competitors at listing time. The free hook is the acquisition mechanism; the per-call ratio matters more than the absolute price (people compare ”$/1k calls”).

For url-intel, the metadata endpoint is the free hook (cheap to serve, no Chrome); screenshot/PDF are the revenue endpoints (expensive to serve, paid tiers only).

MCP as the second channel

MCP marketplaces (Apify ~80% rev share, MCPize ~85%) are an emerging second lane for the same backend. A thin MCP wrapper around your HTTP API:

Reuses the same backend, same proxy-secret pattern
Sells to a different buyer class (AI agents, not human devs)
Currently under-supplied: <5% of 17k+ MCP servers are monetized

This is weekend #2 in the mini-apps plan. See Model Context Protocol.

The risks (and mitigations)

Risk	Mitigation
Marketplace changes terms / shuts down	Own your code + infra; keep the OpenAPI spec portable; never marketplace-lock
Marketplace squeezes margins	Step 2 ladder: keep direct option open
Marketplace’s customer ≠ your customer	True for v1; build email capture into the response (`X-Powered-By: url-intel.kulify.me`) for direct funnel later
Marketplace gates require approvals	Listing review is days, not weeks — but for higher-risk categories (data, scraping), have a clean SSRF guard story ready (ssrf-guard)

DDoS is the marketplace’s problem (and on PPE, it’s revenue)

A non-obvious consequence of marketplace-fronted distribution: upstream DDoS is no longer your problem. The marketplace gateway is the public face; attackers don’t hit your origin directly (and the proxy-secret check rejects them if they try).

On subscription-tiered billing (RapidAPI’s $25/$75/$150 shape), high traffic from a single customer just consumes their monthly quota and trips their hard cap — the marketplace stops forwarding and you don’t see it.

On pay-per-event billing (apify PPE model), the math goes one step further: every event the attacker triggers bills the attacker’s own marketplace account. They drain their own quota; you collect 80% of each billed event. The economic incentive flips — flooding your endpoint costs the attacker money and pays you. The only DDoS-like flood that hurts you is one targeting your origin URL directly (bypassing the marketplace), which the proxy-secret middleware drops at the app layer and which Cloudflare proxy mode (orange cloud) can drop at edge for free if you turn it on.

Implication for your architecture: don’t build in-app rate limits as DDoS protection. Build them only as a backstop against marketplace misconfig (stuck retry loops, runaway customer scripts). The marketplace itself is the real DDoS shield, and on PPE it inverts the threat model into a revenue opportunity.

Where this matters in kulify

Every product in mini-apps/overview uses this pattern. url-intel/overview is the first instance — RapidAPI listing planned for Phase 4 of its weekend build. The MCP wrapper (weekend #2) is the first instance of the second channel.

It is not the right pattern for fajb-next (B2B, custom contracts), katastar (regulated data + government users), or manzas (B2B SaaS with dashboards) — those need direct sales infrastructure.

mini-apps/overview — the umbrella that uses this pattern
url-intel/overview — first instance
rapidapi — the marketplace
Model Context Protocol — the second channel for v2
weekend-micro-saas-series — the broader playbook this is one decision in