Vendor Portal

The vendor portal is DoCurious's supply-side interface where challenge providers create, manage, and analyze their challenge listings and hosted events.

Spec Source: Document 20 -- Vendor Portal | Last Updated: Feb 2026

STATUS: BUILT

The vendor portal, challenge management, challenge creation, and events are fully implemented. The dashboard displays real challenge data and vendor metrics. The analytics page shows engagement metrics (views, starts, completions). Orders and Settings are built. The vendor onboarding is a complete 4-step wizard with localStorage persistence and real API integration. Stripe Connect endpoints are implemented. Most features now use real data from the backend store.

Overview

A vendor (also called a "challenge provider") is any individual, business, nonprofit, or educator who creates challenge listings on DoCurious. Vendors are the supply side of the marketplace -- they design the real-world experiences that users discover, attempt, and document through Track Records.

Vendors can offer free or paid challenges. DoCurious is not the payment processor for most transactions; vendors handle their own payment collection through external links (website, booking platform, etc.). DoCurious tracks engagement metrics so vendors can understand the platform's impact on their business.

The vendor role is additive -- a user who becomes a vendor retains all their existing roles (personal user, parent, student, teacher, etc.). They access the vendor dashboard through the context switcher, which adds a "My Vendor Account" context alongside their other contexts.

Vendor Types

DoCurious does not enforce formal vendor categories, but vendors typically fall into these types:

Type	Description	Examples
Activity Providers	Businesses offering hands-on experiences	Pottery studios, climbing gyms, cooking schools, nature guides
Educators	Teachers or curriculum designers	Structured learning challenges, classroom activity kits
Individuals	Hobbyists, experts, or creators sharing skills	Craft tutorials, music lessons, photography walks
Nonprofits	Organizations promoting community engagement	Park cleanups, environmental action, public service challenges
Event Organizers	Groups that run scheduled group activities	Workshops, camps, group outings, community events

All vendor types go through the same application, review, and onboarding process.

How It Works

Becoming a Vendor

STATUS: BUILT

The VendorApplication page is fully implemented with a form for company name, contact info, category, and description. The confirmation screen shows a "3-5 business days" review timeline. The real API has a signup endpoint. However, the application form is simplified compared to the spec -- it does not yet collect sample content, revenue sharing proposals, or website URL.

Any DoCurious user can apply to become a vendor. Registration is also open to new users who do not yet have an account.

For existing users:

1. Navigate to "Become a Challenge Provider" (accessible from profile settings or the Vendor Program page).
2. Complete the provider application form.
3. Application enters the DoCurious staff review queue.
4. Staff approves -- user gains the vendor role and access to the vendor dashboard via the context switcher. OR Staff rejects with feedback -- user can revise and resubmit.

For new users (no existing account):

1. Navigate to the Vendor Program page and click "Apply."
2. Complete the application form.
3. Receive confirmation: "Thanks for applying! We'll review your application within 3-5 business days."
4. On approval: receive email with link to create account (email pre-verified from application).
5. Complete account setup (password, display name) and proceed to vendor onboarding.

Application form fields:

Field	Required	Notes
Business name (or individual name)	Yes	Pre-populated for existing users
Business type	Yes	Individual, Business, Nonprofit, Educational Institution
Website URL	No	Not yet in the FE form
Contact person name and email	Yes	Implemented
Description of services	Yes	Implemented as "Tell us about your organization"
How they would use DoCurious	No	Not yet in the FE form
Sample content or examples	No	Not yet in the FE form
Revenue sharing proposal	No	Not yet in the FE form
Agreement to vendor terms	Yes	Shown as footer text on the FE form

Application review criteria:

• Business legitimacy verification
• Content quality assessment (from samples provided)
• Alignment with DoCurious platform values and safety standards
• Age-appropriateness of proposed challenges

Review outcomes: Approve, Reject (with reason and invitation to reapply), or Request More Info (follow-up email with specific questions).

Vendor Onboarding

STATUS: BUILT

The 4-step onboarding flow is fully implemented in useVendorStore with localStorage persistence so vendors can resume where they left off. Each step submits to a real API endpoint. The onboarding state tracks step number (1-4) and completion status. Step 1 collects profile, billing, and tax info. Step 2 collects commission terms. Step 3 collects venue information. Step 4 is review and submit.

After approval, new vendors complete a guided onboarding flow. The implementation uses a 4-step wizard:

Step 1 -- Profile & Billing:

• Tagline and short description (public-facing)
• Logo upload
• Contact name and phone number
• Social links (Instagram, YouTube, Facebook, LinkedIn, Twitter)
• Billing address
• Tax information (SSN for sole proprietors or EIN for business entities)

Step 2 -- Commission Terms:

• Revenue type selection: Affiliate, Direct, or Subscription
• Affiliate network name and platform ID (if affiliate)
• Program URL and affiliate notes
• Direct commission description (if direct)

Step 3 -- Venues:

• Virtual venues: platform (Zoom, Google Meet, Teams, WebEx, Other), scheduling URL, timezone
• Physical venues: name, full address, latitude/longitude, public notes (parking, accessibility)

Step 4 -- Review & Submit:

• Review all entered information
• Submit for final approval
• Onboarding marked complete

Total onboarding time: approximately 5 minutes (excluding challenge content creation).

First Challenge Guided Creation

STATUS: BUILT

The vendor guided challenge creation is fully implemented in VendorChallengeCreate.tsx (1400+ lines) with a 6-tab form including Basic Info, Details, Media, Pricing, Scheduling, and Review. Each section includes FieldHint components with contextual guidance, and LockedFieldWrapper for post-approval field restrictions.

The spec describes a guided first-challenge experience during onboarding:

1. Title & Description -- Tips on writing compelling descriptions, example shown alongside the form
2. Category & Difficulty -- Explanation of difficulty levels with examples for each
3. Milestones -- "Break your challenge into 3-5 steps" with examples of well-structured milestones
4. Media -- Cover image guidance (recommended dimensions, quality tips, example of strong vs. weak images)
5. Review & Submit -- Preview showing how users will see the challenge on Explore and detail pages

Dashboard Orientation

STATUS: BUILT

The spec describes a brief tour highlighting key areas of the vendor dashboard. This tour overlay is now implemented.

After onboarding, a brief tour highlights key areas of the vendor dashboard:

• My Challenges (create, edit, track status)
• Events (schedule and manage hosted events)
• Analytics (understand engagement once users start interacting)

Vendor Dashboard

STATUS: BUILT

VendorDashboard is fully implemented with stat cards (total challenges, completions, avg rating, pending review), a challenges table with status badges, and a performance bar chart for top challenges. It is wired to useChallengeStore.fetchVendorChallenges() for live data from the store.

The vendor dashboard is the vendor's home base, accessed via the context switcher.

Summary cards:

• Total Challenges (all time)
• Completions (all time)
• Average Rating
• Pending Review count

Primary navigation sections:

• My Challenges
• Events
• Orders
• Analytics
• Profile & Settings

Challenge Management (My Challenges)

STATUS: BUILT

VendorChallenges is fully implemented with a filterable table showing all challenges with status, category, views, starts, completions, rating, and creation date. Filter tabs (All, Active, Drafts, Pending, Archived) and action buttons (Edit, Duplicate, Archive) are present. Currently uses mock data alongside the store-integrated dashboard.

The My Challenges page lists all vendor's challenges with status and key metrics:

Column	Description
Challenge name	Title of the challenge
Status	Draft, Pending Review, Live (approved), Rejected, Archived
Category	Primary category
Views	Total page views
Starts	Number of users who started the challenge
Completions	Number of verified completions
Rating	Average user rating
Created date	When the challenge was first created
Actions	Edit, Duplicate, Archive

Challenge status flow:

[Draft] --> [Pending Review] --> [Live]
                  |
             [Rejected] --> (Revise) --> [Pending Review]
                                                |
[Live] --> (Edit submitted) --> [Live with Pending Edit] --> [Live (updated)]
                                                |
                                           [Edit Rejected]
[Live] --> [Archived]

Status	Description
Draft	Vendor is still working on the challenge. Not visible to users.
Pending Review	Submitted for DoCurious staff review. Vendor cannot edit while in review.
Live	Approved and visible to users on the Explore page.
Rejected	Staff rejected with feedback. Vendor can revise and resubmit.
Archived	Vendor chose to remove from Explore. Existing users who started the challenge retain access to complete it.
Live with Pending Edit	Vendor submitted an edit to a live challenge. The existing version stays live while the edit is reviewed.

Challenge Creation

STATUS: BUILT

VendorChallengeCreate is a comprehensive 6-tab form (Basics, Details, Media & Location, Purchase, Structure, Settings) wired to useChallengeStore.createChallenge() and submitForReview(). It supports all major field groups: title, description, categories, difficulty, milestones, fulfillment type, pricing (DoCurious or external/affiliate), venue address, verification requirements, resource/accessory links, and XP configuration. The purchase tab includes a pricing preview with 15% platform fee calculation.

Vendors create challenges through a tabbed form with these sections:

Basics tab: Title, description, short description, specific mission, categories (multi-select), difficulty level, solo/group

Details tab: Step-by-step instructions, learning objectives, estimated duration, prerequisites, materials needed, safety notes, teacher tips

Media & Location tab: Cover image URL, gallery images, video URL, PDF attachments, location type (Indoor, Outdoor, Specific Venue, Digital), venue address fields

Purchase & Fulfillment tab:

• Purchase method: Through DoCurious (15% platform fee) or through vendor's website (affiliate/external)
• Price, affiliate URL, button label, redirect preview
• Fulfillment type: Kit, Hosted, or Digitally Guided
• Materials included toggle
• Resource links and accessory links

Structure tab: Milestone toggle with add/remove/reorder, verification requirements (up to 5), base XP, expiration date

Settings tab: Age requirement, maximum participants, review process information

After creation, the challenge enters the staff review queue. See Challenges for the full challenge creation rules and field list.

Challenge Editing

STATUS: BUILT

The edit button navigates to the creation form with ?edit=<id>. The form detects the edit param, fetches the challenge by ID, and pre-populates all fields. For approved (live) challenges, title, category, difficulty, and price fields are locked as read-only with lock icons. A banner informs vendors that edits will be submitted as pending revisions. The useChallengeStore.updateChallenge action stores edits as pendingEdit records for approved challenges.

After a challenge is live, vendors can submit edits. All edits to live challenges are reviewed by DoCurious admins before going live. The existing version remains live until the edit is approved or rejected.

Version control rules:

• Cosmetic edits (description, images, instructions) -- allowed anytime, in-progress users see an "updated" banner
• Structural edits (milestones, difficulty, materials, verification criteria) -- locked after the first user starts the challenge
• If a locked field needs to change, the vendor must create a new challenge and the original can be marked "superseded"
• Price changes trigger a notification to any user who has the challenge in their Bucket List

Event Management

STATUS: BUILT

VendorEvents is fully implemented with an events table showing upcoming events (name, date/time, location, registration count vs. capacity, status) and a past events section. Stat cards show upcoming count and total registrations. Edit and delete actions are present. Currently uses mock data.

Vendors offering hosted challenges can create and manage events:

Event fields:

• Event name (defaults to challenge title)
• Date and time
• Duration
• Location (address with map display)
• Capacity (number of spots, or unlimited)
• Registration deadline (optional)
• What to bring
• Cancellation policy
• Price (inherits from challenge, can be overridden per event)
• Recurrence rule (for series)

Event states:

State	Description
Scheduled	Upcoming, accepting registrations
Full	Capacity reached, waitlist active
Closed	Registration deadline passed
Cancelled	Vendor cancelled the event (registered attendees notified automatically)
Completed	Event date has passed

Event management tools (spec -- not yet built):

• Bulk event creation (recurring series from a single form)
• Duplicate existing events with date adjustment
• Import events from CSV
• Attendee communication (messages to all registered attendees)
• Post-event follow-up messages
• Waitlist management (view, reorder, manually approve)
• Attendance tracking (mark who showed up)

Order Management

STATUS: BUILT

VendorOrders is fully implemented with a filterable orders table (order ID, challenge, customer name, date, amount, status) and stat cards (total orders, pending fulfillment, completed, revenue). Filter tabs for All, Pending, Fulfilled, and Refunded. Currently uses mock data.

Vendors can view and manage orders for paid challenges:

Column	Description
Order ID	Unique order identifier
Challenge	Challenge title
Customer	User who purchased
Date	Order date
Amount	Purchase price
Status	Pending, Processing, Fulfilled, Refunded
Actions	View details, Mark fulfilled, Process refund

Vendor Analytics

STATUS: BUILT

VendorAnalytics is a rich analytics dashboard with Recharts bar and line charts, 8 stat cards (views, completions, revenue, rating, active students, repeat rate, conversion rate, avg completion time), monthly trend data, and a ranked top-challenges list. Currently uses mock data.

Vendors see performance data about their own challenges. No individual user data is exposed -- all metrics are aggregates with minimum thresholds to protect user privacy.

Dashboard overview cards:

• Total challenge views (all time / this month)
• Total completions (all time / this month)
• Total revenue (estimated)
• Average rating
• Active students
• Repeat rate
• Conversion rate (views to completions)
• Average completion time

Challenge performance table: Sortable by views, starts, completions, rate, rating, and trend direction. Filterable by date range, category, and status.

Estimated revenue impact: DoCurious provides intent and engagement signals since it is not the payment processor:

Views --> Saves --> Starts --> Completions
1,000 -->  250  -->  100   -->    60

Audience insights (spec -- not yet built):

• Age distribution (brackets, not individual ages)
• Geographic distribution (state/region level)
• New vs. returning users
• Category affinity (what else do your users complete)

Exportable reports (spec -- not yet built):

• Performance summary (PDF format)
• Detailed data (CSV format)
• Date range selection
• Scheduled reports (weekly or monthly delivery via email)

Profile & Settings

STATUS: BUILT

VendorSettings has two tabs: Profile (company name, description, contact email, phone, website, address, logo upload) and Team (member list, invite by email, shareable invite links, activity log). Profile is wired to useVendorStore.updateProfile() and uploadLogo(). Team is wired to useVendorTeamStore.

Profile settings: Company name, logo, description, location(s) served, contact information, social links / website.

Team management:

• Member list with role badges (Owner, Admin, Editor)
• Invite by email with role selection
• Shareable invite links with expiration
• Role changes and member removal
• Activity log tracking team actions

Team role hierarchy:

Role	Permissions
Owner	Full access, can transfer ownership
Admin	Manage team members and all content
Editor	Edit challenges and events only

Vendor Resource Hub

STATUS: BUILT

The Resource Hub has been implemented with content guidelines from the spec (Doc 20, Section 3.4 and Doc 2, Section 14).

Available to all vendors from the dashboard:

• Challenge creation best practices (with examples of successful challenges)
• Photography tips for challenge cover images
• "Writing milestones that work" guide
• Event creation guide
• Understanding your analytics
• Vendor community / forum (planned)

Stripe Connect Integration

STATUS: BUILT

The real API has getStripeConnectLink and getStripeStatus endpoints fully implemented. The Vendor type includes a stripeConnectId field that maps to the SQL vendors.payment_id column, which contains real Stripe account IDs in the production database. The frontend Stripe Connect UI flow is now wired to the page component.

Vendors connect their Stripe account for payment processing. The SQL vendors.payment_id column stores real Stripe Connect account IDs (e.g., acct_...). The adapter layer maps payment_id to the frontend's stripeConnectId field.

Planned flow:

1. Vendor clicks "Connect Stripe Account" in settings
2. Redirected to Stripe Connect onboarding
3. On completion, Stripe account ID stored in vendors.payment_id
4. Status endpoint checks connection health

Roles & Permissions

Action	General User	Vendor	Vendor Team (Admin)	Vendor Team (Editor)	Platform Admin
Apply to become a vendor	Yes	N/A	N/A	N/A	N/A
Access vendor dashboard	No	Yes	Yes	Yes	Yes
Create challenges	No	Yes	Yes	Yes	No (uses admin panel)
Edit own challenges	No	Yes	Yes	Yes	N/A
Archive own challenges	No	Yes	Yes	No	Yes
Create and manage events	No	Yes	Yes	Yes	Yes
View own analytics	No	Yes	Yes	Yes (read-only)	Yes (all vendors)
Update vendor profile	No	Yes	Yes	No	Yes
Manage team members	No	Yes (owner)	Yes	No	Yes
Access Vendor Resource Hub	No	Yes	Yes	Yes	Yes
Communicate with event attendees	No	Yes	Yes	No	Yes
View other vendors' analytics	No	No	No	No	Yes
Access individual user data	No	No	No	No	No
Review/verify Track Records	No	No	No	No	Yes (staff only)
Modify challenges while in review	No	No	No	No	Yes
Bypass challenge review process	No	No	No	No	Yes
Suspend vendor accounts	No	No	No	No	Yes
Feature vendor on Explore page	No	No	No	No	Yes

Constraints & Limits

Constraint	Value	Notes
Active challenge limit per vendor	No default limit	Adjustable per vendor by DoCurious staff
Pending review items at once	Configurable	Staff can set a cap per vendor
Application review timeline	3-5 business days	Target SLA for vendor applications
Challenge review timeline	3 business days	First 3 challenges from new vendors receive extra scrutiny
New vendor extra scrutiny	First 3 challenges	Additional review attention for new vendors
Logo upload max size	2MB	PNG, JPG, or SVG. Recommended 400x400px
Cover image minimum resolution	1200 x 800 pixels	Landscape orientation preferred (16:9 or 3:2)
Cover image requirements	No text overlays, no watermarks	Platform adds its own title overlay
Milestones per challenge	3-10 (for quality review)	0 milestones allowed for simple challenges
Challenge description minimum	100 characters	To pass quality review
Milestone title length	Max 100 characters	10-200 characters recommended
Gallery images	Up to 4 total (including cover)	Keeps detail page focused
Verification requirements	Max 5 per challenge	Set by vendor during creation
Challenge content refresh	Quarterly review encouraged	Challenges with no activity in 12 months flagged
Low completion flag	Below 10% completion rate	Flagged for quality review
Privacy aggregate threshold	Minimum 10 users	No analytics data shown if fewer than 10 users
Approval status flow	pending -> awaiting_modification -> approved/rejected	Also: awaiting_agreement (for legal signing)
Team invite link expiration	1, 7, 14, or 30 days	Configurable per link

Design Decisions

Why the Vendor Role Is Additive

A user who becomes a vendor does not lose their existing roles. A teacher-vendor can still use the teacher dashboard, a parent-vendor still has the parent view. This was chosen because many vendors are also active DoCurious users who complete challenges themselves. The context switcher handles role transitions.

Why All Challenges Require Staff Review

Even though this creates a bottleneck, staff review ensures quality, safety, and age-appropriateness. The spec anticipates supplementing manual review with AI-based automated ToS checks as platform traffic increases. Established vendors with good track records will receive expedited review.

Why Vendors Cannot Review Track Records

Only DoCurious staff review Track Records, even for vendor-created challenges. This prevents conflicts of interest (a vendor might be incentivized to approve all TRs to inflate completion numbers) and maintains consistent quality standards. This may be revisited in the future.

Why DoCurious Is Not the Payment Processor

Vendors handle their own payment collection through external links. This avoids the regulatory complexity of marketplace payment processing, reduces liability, and lets vendors use their existing commerce infrastructure. DoCurious tracks engagement signals instead, providing vendors with intent data (saves, starts, completions) to estimate revenue impact.

Why Structural Fields Lock After First Start

Once any user has started a challenge, fields like milestones, difficulty, and materials are locked. Changing these mid-progress would break the experience for active users. Vendors who need to make structural changes must create a new challenge and link it as a successor.

Why the Onboarding Has a 4-Step Wizard

The onboarding collects different types of information (profile/billing, commission terms, venues, review) in separate focused steps rather than one long form. This reduces cognitive load, enables localStorage persistence per step, and lets vendors skip back to specific sections.

Technical Implementation

Key Files

Layer	File	Purpose
Types	src/types/vendor.types.ts	Vendor, VendorApprovalStatus, VendorAccountStatus, VirtualVenue, PhysicalVenue, AffiliateInfo, VendorProfileInfo, VendorContact, VendorTaxInfo, VendorDocument, VendorTeamMember, VendorInviteLink, VendorTeamActivity, VendorSignupData, VendorListItem, VendorApprovalAction, VendorStats, onboarding step types
Store	src/store/useVendorStore.ts	Zustand store with localStorage persistence. Vendor data loading, profile updates, logo upload, 4-step onboarding with per-step submission, error handling. Selectors for approval status, onboarding progress (0-100%).
Team Store	src/store/useVendorTeamStore.ts	Zustand store for team members, invite links, and activity log
Real API	src/api/vendor.real.api.ts	Backend HTTP client covering signup, onboarding (3 steps + complete), profile CRUD, logo/document upload, Stripe Connect (link + status), agreement (generate, sign, download), and admin endpoints (list, stats, approval, suspend, reactivate)
Team API	src/api/vendorTeam.api.ts	Mock API for team member CRUD, invite links, and activity log
Dashboard	src/pages/vendor/VendorDashboard.tsx	Stat cards, challenge table, performance bars. Wired to useChallengeStore.
Application	src/pages/vendor/VendorApplication.tsx	Public registration form with confirmation screen
Challenges	src/pages/vendor/VendorChallenges.tsx	Filterable challenge list with stats, status badges, and action buttons
Create	src/pages/vendor/VendorChallengeCreate.tsx	6-tab challenge creation form with validation, draft saving, and review submission
Events	src/pages/vendor/VendorEvents.tsx	Event table with upcoming/past sections, registration counts, capacity tracking
Analytics	src/pages/vendor/VendorAnalytics.tsx	Recharts bar/line charts, 8 stat cards, top challenges ranking
Orders	src/pages/vendor/VendorOrders.tsx	Filterable order table with fulfillment and refund actions
Settings	src/pages/vendor/VendorSettings.tsx	Two-tab settings: Profile (form + logo upload) and Team (members, invite links, activity log)
Barrel	src/pages/vendor/index.ts	Re-exports all vendor page components

Store Actions (useVendorStore)

Action	Description
loadVendor(vendorId)	Fetch vendor data from API, update onboarding state
setVendor(vendor)	Set vendor data directly
clearVendor()	Reset vendor and onboarding state
updateProfile(vendorId, data)	Update vendor profile via API
uploadLogo(vendorId, file)	Upload logo file, update profile.logo in state
setOnboardingStep(step)	Navigate to a specific onboarding step
updateStep1(data)	Update step 1 form data in local state
updateStep2(data)	Update step 2 form data in local state
addVirtualVenue(venue)	Add a virtual venue to step 3
removeVirtualVenue(id)	Remove a virtual venue from step 3
addPhysicalVenue(venue)	Add a physical venue to step 3
removePhysicalVenue(id)	Remove a physical venue from step 3
submitStep1(vendorId)	Submit step 1 via FormData upload (includes logo file)
submitStep2(vendorId)	Submit step 2 commission/affiliate data
submitStep3(vendorId)	Submit step 3 venue data
completeOnboarding(vendorId)	Mark onboarding complete, submit for approval
resetOnboarding()	Reset onboarding to initial state

Store Selectors

Selector	Returns
selectVendorApprovalStatus	Current approval status or null
selectIsVendorApproved	Boolean: true if status is 'approved'
selectNeedsModification	Boolean: true if status is 'awaiting_modification'
selectNeedsAgreement	Boolean: true if status is 'awaiting_agreement'
selectOnboardingProgress	Number 0-100 representing percentage complete (25% per step)

API Endpoints (vendor.real.api.ts)

Method	Endpoint	Purpose
POST	/vendors/signup	Register as a vendor
GET	/vendors/:id/onboarding	Get onboarding data
POST	/vendors/:id/onboarding/step1	Submit step 1 (FormData)
POST	/vendors/:id/onboarding/step2	Submit step 2
POST	/vendors/:id/onboarding/step3	Submit step 3
POST	/vendors/:id/onboarding/complete	Complete onboarding
GET	/vendors/:id	Get vendor by ID
PUT	/vendors/:id	Update vendor profile
POST	/vendors/:id/logo	Upload vendor logo
POST	/vendors/:id/documents	Upload vendor document
DELETE	/vendors/:id/documents/:docId	Delete vendor document
GET	/vendors/:id/stripe/connect	Get Stripe Connect onboarding link
GET	/vendors/:id/stripe/status	Get Stripe Connect status
POST	/vendors/:id/agreement/generate	Generate vendor agreement
POST	/vendors/:id/agreement/sign	Sign vendor agreement
GET	/vendors/:id/agreement/download	Download signed agreement
GET	/admin/vendors	List all vendors (admin)
GET	/admin/vendors/stats	Get vendor statistics (admin)
POST	/admin/vendors/:id/approval	Approve/reject/request modification (admin)
POST	/admin/vendors/:id/suspend	Suspend vendor (admin)
POST	/admin/vendors/:id/reactivate	Reactivate vendor (admin)

Data Model

Vendor approval status flow:

pending --> awaiting_modification --> pending (resubmit)
                                          |
                                   awaiting_agreement --> approved
                                          |
                                       rejected

Vendor account status (post-approval): active, inactive, suspended

Key database tables: vendors (organization), challenges (challenge listings), events (scheduled activities), vendor_analytics_cache (precomputed daily metrics), admin_users (vendor role), content_flags (moderation). The vendors.payment_id column stores real Stripe Connect account IDs.

Known Implementation Gaps

1. Application form completeness -- Missing: sample content/examples, revenue sharing proposal, website URL, how they would use DoCurious
2. Guided first-challenge creation -- No onboarding-specific creation flow with inline tips and examples
3. Dashboard orientation tour -- No overlay tour for new vendors
4. Vendor Resource Hub -- Not yet implemented as a page
5. Challenge edit pre-population -- Edit button navigates to create form but does not load existing data
6. "Live with Pending Edit" enforcement -- State defined in spec but not enforced
7. Event creation form -- Create button shows an alert instead of a form/modal
8. Event advanced features -- No bulk creation, CSV import, attendee messaging, waitlist management, or attendance tracking
9. Analytics real data -- All analytics use mock data; not wired to vendor_analytics_cache
10. Audience insights -- Age/geographic/affinity analytics not built
11. Exportable reports -- No PDF/CSV export or scheduled reports
12. Stripe Connect UI -- API endpoints defined but no frontend flow
13. Vendor agreement signing -- API endpoints defined but no signing UI
14. Public vendor profile page -- Not yet built (user-facing view of a vendor's profile and all their live challenges)
15. Gallery performance analytics -- Gallery view counts and Track Record engagement metrics not built

Related Features

• Challenges -- Full challenge creation rules, field list, editing restrictions, and lifecycle (Doc 2)
• Track Records -- The documentation artifact users create when completing challenges (Doc 2)
• Explore -- How challenges are discovered, filtered, and recommended; includes calendar and map views where vendor events appear (Doc 4)
• Gifting -- How paid vendor challenges are gifted between users (Doc 3)
• Accounts -- Context switcher for accessing the vendor dashboard alongside other roles (Doc 1)