Partner Programs and Bounties
Purpose and Scope
Partner programs in Dub are the product area that connects link attribution to relationships with external promoters, affiliates, creators, or other partners. In the first-party product language, partners join programs, receive referral links, measure performance, and view earnings. In the repository, that concept appears in two main places for this page: an API surface registered under partner-related OpenAPI paths, and Enterprise Edition dashboard code for partner-program management. Bounties sit inside that same partner-program context as engagement mechanisms that reward partners for completing goals or submitting work.
Sources: apps/web/lib/openapi/partners/index.ts, apps/web/lib/openapi/bounties/index.ts, apps/web/app/(ee)/README.md
This page is intended for developers trying to understand how the partner-program and bounty concepts are reflected in Dub’s source layout, not as an exhaustive product manual. The key distinction is that “partners” are relationship-management resources with lifecycle, links, analytics, and applications, while “bounties” are program engagement resources whose public API evidence in this slice focuses on reviewing submissions. The dashboard evidence shows that program operations also include resource management for brand assets, which helps program owners give partners approved logos, colors, files, and links.
Sources: apps/web/lib/openapi/partners/index.ts, apps/web/lib/openapi/bounties/index.ts, apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/resources/program-brand-assets/index.tsx
Relevant Source Files
apps/web/lib/openapi/partners/index.ts- Registers the partner-related OpenAPI path map, including partner creation and listing, applications, partner links, analytics, approval, rejection, banning, and deactivation.apps/web/lib/openapi/bounties/index.ts- Registers the bounty-submission OpenAPI path map for listing submissions and approving or rejecting a specific submission.apps/web/app/(ee)/README.md- Defines theapps/web/app/(ee)subtree as the Enterprise Edition home for hosted and enterprise-grade features, explicitly including Dub Partners and noting the Enterprise license restriction.apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/resources/program-brand-assets/index.tsx- Implements the dashboard brand-assets settings area for a partner program, including logos, colors, files, links, modal editing flows, deletion, and mutation after changes.
Concept Model
A partner program is best understood as a structured workspace-owned program that lets the business enroll and manage partners. The API path map exposes the operational verbs around that relationship: create or list partners, list applications, approve or reject applications, create or retrieve partner links, upsert a partner link, retrieve partner analytics, ban a partner, or deactivate a partner. Those verbs are not generic account-management actions; they describe the lifecycle of an affiliate-program participant after they discover, apply to, join, promote, and eventually produce measurable results for a program.
Sources: apps/web/lib/openapi/partners/index.ts
Applications represent the admission side of the program. The official product flow describes partners browsing a marketplace, reviewing program details, and applying when the program fits their audience. The repository evidence maps that product flow to GET /partners/applications plus approval and rejection routes. That separation is useful: listing applications is a review queue, while approve and reject are explicit state transitions. When building integrations or internal tools, treat application review as its own workflow rather than as a side effect of listing partners.
Sources: apps/web/lib/openapi/partners/index.ts
Partner links are the attribution bridge between the program and Dub’s core short-link platform. The partner path map contains both POST /partners/links and GET /partners/links, plus PUT /partners/links/upsert. That shape suggests two common integration patterns: create a link when onboarding or assigning a partner, and idempotently upsert a link when the caller wants the API to converge on a desired link state without first deciding whether it exists. Analytics then closes the loop through GET /partners/analytics, giving program operators or partner-facing experiences a way to retrieve performance.
Sources: apps/web/lib/openapi/partners/index.ts
Bounties are narrower in the OpenAPI evidence for this page. The registered bounty paths are scoped to a bountyId and operate on submissions beneath that bounty. A caller can list submissions for a bounty, approve a specific submission, or reject a specific submission. This aligns with the product concept of submission bounties, where partners submit content or proof of work and program operators review it. Performance bounties may be tracked automatically at the product level, but the source evidence here only establishes the submission-review API family.
Sources: apps/web/lib/openapi/bounties/index.ts
System-to-Code Mapping
The partner and bounty API modules are OpenAPI assembly points. Each file imports operation definitions from sibling modules and exports a ZodOpenApiPathsObject, which is the path map consumed by Dub’s broader OpenAPI generation flow. The important source-level detail is that these files do not implement business logic directly. Instead, they declare which HTTP paths exist and which imported operation object owns each method. For readers extending the API reference, these files are the index-level source of truth for the route families and their method-to-operation wiring.
Sources: apps/web/lib/openapi/partners/index.ts, apps/web/lib/openapi/bounties/index.ts
| Area | Registered path | Method | Imported operation | Meaning |
|---|---|---|---|---|
| Partners | /partners | POST | createPartner | Create a partner record. |
| Partners | /partners | GET | listPartners | List partners. |
| Applications | /partners/applications | GET | listPartnerApplications | List partner applications. |
| Partner links | /partners/links | POST | createPartnerLink | Create a partner referral link. |
| Partner links | /partners/links | GET | retrievePartnerLinks | Retrieve partner links. |
| Partner links | /partners/links/upsert | PUT | upsertPartnerLink | Create or update a partner link through an upsert flow. |
| Analytics | /partners/analytics | GET | retrievePartnerAnalytics | Retrieve partner analytics. |
| Applications | /partners/applications/approve | POST | approvePartner | Approve an application. |
| Applications | /partners/applications/reject | POST | rejectPartner | Reject an application. |
| Partner status | /partners/ban | POST | banPartner | Ban a partner. |
| Partner status | /partners/deactivate | POST | deactivatePartner | Deactivate a partner. |
| Bounty submissions | /bounties/{bountyId}/submissions | GET | listBountySubmissions | List submissions for a bounty. |
| Bounty submissions | /bounties/{bountyId}/submissions/{submissionId}/approve | POST | approveBountySubmission | Approve a submission. |
| Bounty submissions | /bounties/{bountyId}/submissions/{submissionId}/reject | POST | rejectBountySubmission | Reject a submission. |
The dashboard code lives in the Enterprise Edition tree, which matters for both architecture and licensing. The apps/web/app/(ee)/README.md describes the /(ee) subfolder as the place for Enterprise Edition features from Dub’s hosted and enterprise plans, including Dub Partners. It also warns that this code is copyrighted and requires an enterprise license to host as an app.dub.co replacement. Developers should therefore distinguish open API schema registration from enterprise dashboard implementation: both are in the repository, but not every partner-program feature is equally available for self-hosted use without licensing.
Sources: apps/web/app/(ee)/README.md
Dashboard Resource Management
The ProgramBrandAssets component shows a concrete program-management area rather than an abstract API registration. It is a client component for the dashboard route under app.dub.co, the workspace slug, the Enterprise Edition segment, and program resources. It loads the current workspace through useWorkspace, loads program resources through useProgramResources, and renders a brand-assets settings panel. The visible UI copy describes “Brand Assets” as logos, colors, and additional documents, which matches the partner-facing need for consistent promotional material.
Sources: apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/resources/program-brand-assets/index.tsx
The component models four editable resource families: logos, colors, files, and links. Each family has separate editing state, and each modal hook receives the existing resource when the user is editing rather than creating. That pattern is important because program resources are not just static uploads; they are managed assets with create and update flows. Program owners can add a logo, edit an existing logo, add or edit color values, add or edit files, and add or edit resource links, all within the same brand-assets panel.
Sources: apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/resources/program-brand-assets/index.tsx
Deletion is handled through a server action wrapper, deleteProgramResourceAction, executed with useAction from next-safe-action/hooks. The delete handler passes workspaceId, resourceType, and resourceId, then returns whether the action reported success. On success, the component shows a toast that capitalizes the deleted resource type and calls mutate() so the resource list refreshes. On error, it shows either the server error or a fallback message. This gives contributors a clear UI-state pattern for partner-program settings: optimistic-looking feedback, server-mediated mutation, and SWR revalidation.
Sources: apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/resources/program-brand-assets/index.tsx
API Components
The compact API reference for this page should be read as a route-family inventory rather than full schema documentation. The exported names partnersPaths and bountiesPaths are the public assembly points visible in the supplied source. Both are typed as ZodOpenApiPathsObject, indicating that Dub’s OpenAPI definitions are composed as Zod-backed path objects. If you are adding generated API docs, SDK bindings, or route coverage checks, these index modules are where partner and bounty path membership can be verified before drilling into individual operation files.
Sources: apps/web/lib/openapi/partners/index.ts, apps/web/lib/openapi/bounties/index.ts
Partner operations cover four reader tasks. First, program operators can create and list partners. Second, they can review applications by listing, approving, or rejecting them. Third, they can manage attribution links through create, retrieve, and upsert operations. Fourth, they can inspect performance or change participation status through analytics, ban, and deactivate routes. This organization reflects the product journey: discover and apply, become a partner, receive or manage links, generate activity, then remain active, be deactivated, or be banned depending on program policy.
Sources: apps/web/lib/openapi/partners/index.ts
Bounty operations cover the review queue for submissions attached to a specific bounty. The path parameters make the hierarchy explicit: a submission is reviewed in the context of its bountyId, and approval or rejection targets a submissionId under that bounty. This is the right mental model when designing clients. A client should first select or know the bounty, then list its submissions, then apply a review action to the chosen submission. Avoid modeling bounty submission approval as a global action detached from the bounty context.
Sources: apps/web/lib/openapi/bounties/index.ts
Execution Flow
A typical partner-program workflow begins when a prospective partner discovers a program through the partner-facing product experience and applies. On the operator side, the API has a path for listing applications and separate paths for approving or rejecting them. After approval, the program can create or upsert partner links so attribution is tied to the partner’s promotional activity. As performance accumulates, the analytics route gives a way to retrieve partner-level results, while status routes support administrative actions such as banning or deactivation.
Sources: apps/web/lib/openapi/partners/index.ts
A typical bounty workflow starts inside an existing partner program rather than at the generic link layer. Program operators create bounties in the product experience to drive partner engagement, and submission-oriented bounties produce reviewable submissions. The API evidence for this page begins at that review stage: list submissions for a given bounty, approve the submissions that meet requirements, and reject the ones that do not. Performance-based bounty automation is a product concept, but the source-backed integration point here is the submission review lifecycle.
Sources: apps/web/lib/openapi/bounties/index.ts
A typical dashboard resource workflow supports the enablement side of the program. Program operators prepare brand assets so partners can promote the product consistently. The component fetches resources, opens a modal for the resource type being created or edited, and deletes resources through a safe action when needed. After mutation, the resource list is refreshed. This means partner-program UX is not limited to applications and payouts; it also includes the operational material partners need to produce approved content and campaigns.
Sources: apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/resources/program-brand-assets/index.tsx
Implementation Notes and Next Steps
When working in this area, keep the boundary between product concepts, API path registration, and dashboard implementation clear. The OpenAPI index files tell you what route families exist and which operation modules they delegate to. The Enterprise Edition README tells you where hosted and enterprise-grade partner features live and what licensing posture applies. The dashboard brand-assets component shows how one program-management experience is implemented with workspace context, SWR data, modal editing, server actions, toasts, and mutation.
Sources: apps/web/lib/openapi/partners/index.ts, apps/web/lib/openapi/bounties/index.ts, apps/web/app/(ee)/README.md, apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/resources/program-brand-assets/index.tsx
For deeper implementation work, follow the imported operation names from the OpenAPI index modules into their sibling files, then inspect the matching application routes or server actions that execute the behavior. For product and integration planning, read this page alongside the API reference pages for bounties, customers and partners, commissions, payouts, and track events. Together, those pages explain how Dub moves from partner enrollment and referral links to attribution, rewards, financial operations, and reporting.