Partner Portal

The Tripinger partner portal is the authenticated workspace for supply-side operators on the platform. It allows hotels, vehicle owners, restaurants, guides, and other approved partners to manage listings, availability, pricing, bookings, documents, and day-to-day operations from one web interface.

Purpose

Tripinger is built as an integrated marketplace spanning hotels, vehicle rentals, food arrangements, activities, planning, reviews, and community features. That marketplace only works if supply-side partners have a reliable portal where they can onboard, maintain inventory, respond to bookings, and keep their operational data current.

Why the portal matters

The blueprint directly describes:

• an owner onboarding portal for local vehicle owners,
• a property dashboard for hotel managers,
• a restaurant dashboard for menus and availability,
• verified supplier flows for guides and travel services,
• availability calendars and dynamic pricing,
• booking-linked trust and review systems.

Those requirements make the partner portal a core Phase 1 product surface, not an optional later tool.

Supply-side roles supported

The platform’s revenue model depends on partner participation across multiple categories, especially hotels and vehicle rentals in the MVP. The partner portal should therefore be designed to support multiple partner personas under a consistent structure.

Expected partner types:

• hotel managers,
• villa and guesthouse operators,
• vehicle owners,
• rental fleet operators,
• restaurant partners,
• guides and activity providers,
• local experience hosts,
• future corporate or package operators.

Technology alignment

The partner portal should follow the same frontend standards as the other Tripinger web surfaces.

Phase 1 priorities

The MVP roadmap prioritizes user auth, hotel listing search, hotel booking, tuk-tuk rental listings, vehicle booking, itinerary building, budget tools, and responsive web delivery. On the partner side, the first portal version should focus on the supplier workflows required to support those customer-facing features.

Recommended Phase 1 priorities:

1. Partner authentication.
2. Partner onboarding and profile completion.
3. Hotel listing creation and updates.
4. Vehicle listing creation and updates.
5. Availability calendar management.
6. Basic pricing controls.
7. Booking inbox or reservation management.
8. Document upload and verification status.
9. Basic analytics and performance summary.

Suggested folder structure

The exact implementation may evolve, but the app should be organized by partner workflows and reusable dashboard primitives.

apps/partner/
├─ src/
│  ├─ main.tsx
│  ├─ App.tsx
│  ├─ app/
│  │  ├─ providers/
│  │  ├─ router/
│  │  ├─ layouts/
│  │  └─ guards/
│  ├─ components/
│  │  ├─ ui/
│  │  ├─ forms/
│  │  ├─ tables/
│  │  ├─ cards/
│  │  ├─ calendars/
│  │  ├─ charts/
│  │  ├─ media/
│  │  └─ feedback/
│  ├─ features/
│  │  ├─ auth/
│  │  ├─ onboarding/
│  │  ├─ dashboard/
│  │  ├─ profile/
│  │  ├─ hotels/
│  │  ├─ vehicles/
│  │  ├─ restaurants/
│  │  ├─ activities/
│  │  ├─ availability/
│  │  ├─ pricing/
│  │  ├─ bookings/
│  │  ├─ payouts/
│  │  ├─ documents/
│  │  ├─ reviews/
│  │  ├─ analytics/
│  │  └─ settings/
│  ├─ lib/
│  │  ├─ api/
│  │  ├─ auth/
│  │  ├─ config/
│  │  ├─ permissions/
│  │  └─ utils/
│  ├─ hooks/
│  ├─ styles/
│  ├─ types/
│  └─ tests/
├─ public/
└─ README.md

Suggested routes

The route tree should reflect the main lifecycle of a partner: join, verify, publish, manage availability, receive bookings, and review performance.

• /login
• /register
• /onboarding
• /
• /dashboard
• /profile
• /listings
• /listings/new
• /listings/:id
• /availability
• /pricing
• /bookings
• /bookings/:id
• /documents
• /reviews
• /analytics
• /payouts
• /settings

If the product later separates route groups by partner type, the underlying concepts should still stay the same.

Partner onboarding

The blueprint makes onboarding quality critical because the platform depends on verified, trusted local supply from hotels, vehicle owners, guides, and other providers. The portal should therefore guide partners through a structured onboarding process rather than exposing the full dashboard immediately.

Recommended onboarding steps:

1. Account creation.
2. Partner type selection.
3. Business or owner profile details.
4. Document upload.
5. Listing basics.
6. Banking or payout setup when enabled.
7. Review and verification status.
8. Approval handoff to admin.

For vehicle owners, the blueprint explicitly mentions registration, insurance, owner identity checks, and compliance-sensitive onboarding, so those fields should be first-class parts of the portal flow.

Hotel partner workflows

Hotels are a primary revenue source in the business model, with lower commission positioned as a major reason for independent properties to join. The portal should therefore make hotel management straightforward and immediately useful.

Hotel capabilities should include:

• property profile editing,
• room or unit configuration,
• rate entry,
• availability updates,
• amenity selection,
• photo uploads,
• booking review,
• response and operational notes,
• promotion setup where enabled,
• review visibility.

The blueprint also mentions a PMS-lite concept for hotel managers, so the portal should be designed to grow into a lightweight property operations tool rather than a static listing form.

Vehicle partner workflows

Vehicle rentals are one of the platform’s strongest differentiators and a major part of the early value proposition. The blueprint describes a marketplace model where local owners register, upload vehicles, set availability, choose pickup details, and earn through the platform.

Vehicle-owner capabilities should include:

• vehicle creation and editing,
• category selection such as tuk-tuk, bike, scooter, or car,
• daily rate setting,
• availability calendar management,
• pickup and drop-off settings,
• photo uploads,
• registration and insurance document handling,
• booking request review,
• issue reporting,
• booking completion confirmation.

The vehicle module should be designed with both single-owner operators and small fleets in mind.

Restaurant and food partner workflows

The food module focuses on tourist-oriented discovery, reservation, meal packages, and curated experiences rather than standard urban delivery. That means restaurant partners need a portal tuned to reservations and discoverability, not courier logistics.

Recommended restaurant capabilities:

• venue profile editing,
• cuisine and dietary tagging,
• menu highlights,
• table or slot availability,
• reservation management,
• special package setup,
• featured food trail participation,
• review monitoring,
• media updates.

Guide and activity partner workflows

The blueprint includes licensed guides, cultural tours, adventure activities, wellness experiences, and last-minute availability management. The partner portal should therefore support operators whose “inventory” is time, availability, and experience configuration rather than rooms or vehicles.

Recommended activity capabilities:

• profile and credential management,
• experience creation,
• schedule and slot setup,
• pricing updates,
• capacity management,
• booking review,
• cancellation handling,
• trust badge visibility,
• review response or monitoring.

Booking management

Across all partner types, booking visibility is a core need. Partners should be able to understand what was booked, when, by whom, and what action is expected next.

Recommended booking views:

• upcoming bookings,
• pending requests if applicable,
• completed bookings,
• cancellations,
• guest or traveler details where allowed,
• payout-relevant status,
• booking notes,
• timeline or status history.

The business model relies on hotel and vehicle bookings from the start, so this area should be treated as a first-class portal surface rather than a secondary report.

Availability and pricing

The blueprint repeatedly highlights real-time availability, dynamic pricing, and live slot management. The partner portal should centralize those controls in an interface that is simple enough for non-technical local operators to use consistently.

Recommended controls:

• calendar-based availability,
• blackout dates,
• minimum notice windows,
• seasonal pricing,
• special rates,
• last-minute deals,
• room or vehicle quantity limits,
• booking lead-time restrictions.

Documents and verification

Supplier trust is a major strategic advantage for the platform, especially because the market it is entering is fragmented and often offline. Partners should always be able to see what documents are required, which ones are approved, and what still needs action.

Recommended document areas:

• uploaded documents list,
• verification status,
• expiry or renewal reminders,
• rejection reasons,
• resubmission flow,
• profile completeness indicator.

Examples from the blueprint include vehicle registration, insurance, owner ID, SLTDA-related verification for relevant operators, and other compliance-sensitive records.

Reviews and reputation

The blueprint positions verified reviews as both a trust layer and a long-term SEO and growth engine. Partners should therefore have visibility into what travelers are saying and how reviews affect their listing credibility.

Useful review features:

• read verified reviews,
• filter by listing,
• monitor average scores,
• identify unresolved complaints,
• view moderation or hidden states,
• receive response capability if enabled later.

Analytics

The platform’s supply side needs enough performance visibility to keep partners engaged and help them improve conversions. Even the first version of the portal should offer lightweight analytics tied to business outcomes.

Recommended early metrics:

• listing views,
• booking volume,
• booking status counts,
• revenue or payout estimate,
• occupancy or utilization trends,
• cancellation rate,
• review score summary,
• top-performing listings.

Payouts and settlement visibility

The blueprint describes escrow-like booking flows and commission-based monetization for hotels, vehicle owners, food reservations, and activities. Even if full finance tooling arrives later, partners should still be able to understand their expected earnings and booking-linked financial state.

Recommended payout features:

• pending earnings,
• released earnings,
• commission summary,
• payout history,
• payout method status,
• blocked or disputed funds indicators.

Environment variables

The partner app should use public-safe frontend configuration variables, likely including:

• VITE_PARTNER_APP_NAME
• VITE_PARTNER_API_BASE_URL
• VITE_PARTNER_BASE_URL
• VITE_PARTNER_SENTRY_DSN

Additional feature flags can be added as partner modules expand.

Local development

Prerequisites

Install:

• Node.js LTS
• pnpm
• the Tripinger API running locally
• access to the root .env file
• Docker if support services are started locally

Typical setup

pnpm install
cp .env.example .env
pnpm docker:up
pnpm --filter partner dev

If the monorepo uses root workspace scripts, prefer those.

Expected local URLs

Partner app: http://localhost:3002
API:         http://localhost:4000/api/v1

Auth and access model

The partner portal should be private and approval-aware. A user may have an account but still be blocked from full publishing or booking operations until verification is complete.

Suggested account states:

• invited,
• registered,
• onboarding,
• pending verification,
• approved,
• suspended.

Suggested partner roles:

• owner,
• manager,
• staff,
• finance viewer,
• read-only user.

UX priorities

The portal should be optimized for clarity and low training overhead because many early partners may not be deeply technical. That is especially important if the first cohorts include independent hotel operators and local vehicle owners who currently rely on phone calls, WhatsApp, or manual booking methods.

Important UX patterns:

• clear onboarding progress,
• simple forms,
• mobile-usable dashboard layouts,
• calendar-first inventory management,
• large status labels,
• obvious save and publish actions,
• document and error feedback,
• lightweight analytics cards,
• multilingual readiness for future Sinhala and Tamil support.

Testing expectations

At minimum, the portal should support:

• auth and route guard tests,
• onboarding flow tests,
• listing creation tests,
• document upload state tests,
• availability update tests,
• booking table and detail tests,
• analytics view smoke tests.

Highest-priority Phase 1 test flows:

1. Partner registration and login.
2. Onboarding progression.
3. Hotel listing creation.
4. Vehicle listing creation.
5. Availability calendar update.
6. Booking detail review.
7. Verification-blocked account behavior.

Deployment direction

Like the public and admin web surfaces, the partner portal should deploy cleanly as an API-driven frontend with environment-specific configuration. It should remain separate from the public traveler app while still sharing design and engineering conventions across the monorepo.

Recommended deployment properties:

• private authenticated routes,
• environment-based API endpoints,
• error tracking,
• media upload support,
• protected route fallback handling,
• performance-conscious dashboard pages.

Contribution guidance

When adding a new partner capability:

1. Place it under src/features/<domain>.
2. Reuse shared dashboard primitives where possible.
3. Account for partner-type differences early.
4. Include loading, empty, blocked, and error states.
5. Keep forms resilient for slower networks and mobile widths.
6. Document any new env variables in the root .env.example.
7. Update this README if the app-level structure changes.

Current status

This README defines the intended structure and responsibilities of the Tripinger partner portal based on the startup blueprint and approved Phase 1 architecture sequence. Exact scripts, route labels, and package-level implementation details should be aligned with the repository once the partner app scaffold is committed.