Creating and reviewing bounties

Bounties are one-off, task-based rewards for your partners — like "record a YouTube review" or "write a blog post". You (the operator) create a bounty with a fixed reward; a partner completes the task, submits a proof link, and you review the claim. Approving a claim pays the reward by minting a commission that flows through the normal approve → payout pipeline.

In the dashboard

Bounties live at /<workspace>/bounties. Each card shows the reward, status, claim count, and — when there are pending claims — aReview N pending claims button.

1. ●

   Open Bounties and click New bounty

   On /<workspace>/bounties, click New bounty. A side sheet titled Create bounty opens.

2. ●

   Optionally start from a template

   Under Start from a template pick one of the six presets (YouTube video review, Blog post, Twitter thread, Customer case study, Podcast mention, Short-form video). It just pre-fills the title, description, and a suggested reward — you can edit everything.

3. ●

   Fill in the fields

   Set the details partners will see:

   • Program — only shown when the workspace has more than one program.
   • Title — required.
   • Description — what partners need to do (optional).
   • Reward — dollars, required, minimum $1.
   • Max claims — blank means unlimited.

   A Partners will see preview renders once a title and reward are set. Click Create bounty to save.

4. ●

   Review claims as they come in

   When a partner submits a claim the card shows a pending badge. ClickReview N pending claims to open/<workspace>/bounties/<bountyId>/claims. Each claim lists the partner, their note, and a View proof link. Pending claims get Approve / Reject actions.

Claim statuses are pending, approved, andrejected. Bounty statuses are active,paused, and archived. Either way the partner gets an email about the outcome (best-effort — a failed email never blocks the review).

Via the API / for agents

There is no operator-facing API for creating a bounty — the create form posts to POST /api/workspaces/<slug>/bounties, an internal session-authenticated route, so bounty creation is effectively dashboard-only. The two endpoints an external agent would use are the partner claim submission and the operator claim review.

Partner submits a claim

A partner (authenticated as the calling user, matched by email in the bounty's workspace) submits proof:

curl -X POST https://partli.app/api/partner/bounties \
  -H "content-type: application/json" \
  -d '{
    "bountyId": "<uuid>",
    "proofUrl": "https://youtube.com/watch?v=...",
    "note": "Published this morning"
  }'

On success you get the new claim id back:

{ "id": "<claimId>" }  // HTTP 201

The route rejects with 403 if the partner isn'tapproved, and with 409 if the bounty is notactive, has expired, has hit its maxClaimslimit, or the partner already claimed it (one claim per partner per bounty).

Operator approves or rejects a claim

Review a claim via PATCH /api/workspaces/<slug>/bounties/<bountyId>/claims/<claimId>:

curl -X PATCH \
  https://partli.app/api/workspaces/<slug>/bounties/<bountyId>/claims/<claimId> \
  -H "content-type: application/json" \
  -d '{ "status": "approved" }'   # or "rejected"

The body must be exactly { "status": "approved" | "rejected" }; anything else returns 400. The response is the updated claim row.

Approving creates a bounty event and a pendingcommission for bounty.rewardCents, honoring the program'sholdingPeriodDays as the commission's payableAt. It then emits the webhook:

// event: commission.created
{
  "commissionId": "<uuid>",
  "partnerId": "<uuid>",
  "programId": "<uuid>",
  "amountCents": 5000,
  "currency": "usd",
  "type": "bounty"
}

Rejecting a previously-approved claim reverses its unpaid commission — anypending or approved commission for that claim is set to clawed_back with reasonBounty claim rejected.

Gotchas