Skip to content

Build services.Get paid.

Ship APIFuse services with the public SDK and submit them with evidence. Rewards are paid in KRW once maintainers review and merge.

bash
bunx @apifuse/provider-sdk@beta create my-provider --yes
cd my-provider
bun run check && bun run test

No monorepo access. The public SDK is all it takes

Open bounties
151of 178 total
Open reward pool
₩23,770,000sum across open bounties
In flight
2claimed, review, sync
Paid out
₩00 paid

Empty directory to merged service, in four steps

No special access required to start.

  1. 01Find a bounty

    Browse open bounties and pick a target service that matches your tier and skills.

  2. 02Build with the SDK

    Scaffold a standalone service with the public SDK, then replace the starter API with real upstream logic, schemas, fixtures and tests.

  3. 03Pass the checks

    Run check, test and submit-check locally, and back every API with a real healthCheck.

  4. 04Submit evidence

    Share your workspace repository, commit, API list and command output. Operators review and merge.

Tiers and rewards

Rewards scale with service complexity. Every bounty is labeled with its tier.

₩50,000

Simple HTTP services. 1-2 APIs, no auth.

Open now: 71
₩150,000

Secret- or credential-authenticated services. 3-5 APIs.

Open now: 37
₩300,000

TLS-sensitive or browser-assisted services with complex auth.

Open now: 24
₩500,000

Browser + OTP flows and large API surfaces.

Open now: 19

Highest-reward open bounties

The top three, in the board's default order.

Evidence in your workspace, operators handle the rest

Know what a submission needs and what review looks at, before you start.

Evidence to include

  • Workspace repository and main commit link
  • SDK version/tag and the create command used
  • API list with input/output summaries
  • healthCheck or healthCheckUnsupported coverage table per API
  • bun run check and bun run test output

Review criteria

  • Scaffolded from the public @apifuse/provider-sdk
  • Every API implemented with Zod/Standard Schema input & output
  • Each API declares exactly one of healthCheck or healthCheckUnsupported
  • Real upstream fixture data included where applicable
  • Auth, credential and env-secret behavior documented. No real secrets committed

Frequently asked questions

No. The public SDK is enough to start, and an approved claim gets you a dedicated workspace repository.

Use the claim form on an open bounty's detail page. A dedicated workspace is prepared after approval.

After your service is merged and its deployment is confirmed, the reward is paid in KRW.

Prefer a real healthCheck for read-only APIs. Use healthCheckUnsupported only for destructive, paid, credential-sensitive or flaky-by-design probes, and write a specific reason.

Build in the managed workspace repository on main after approval. Replace the starter ping API with real upstream logic, schemas, fixtures and tests.

For Gold and Platinum bounties, verify local runtime prerequisites first: the CycleTLS helper for TLS work, Playwright Chromium for browser work, or a CDP pool URL for remote debugging.

Ready to take your first bounty?

Pick an open bounty, claim it, and build with the public SDK. Real rewards for real integrations.