Dealer portal with leads, billing, and API access

Dealer portal with leads, billing, and API access

The marketplace's consumer side generates demand. The dealer portal monetizes it. Car dealers in the region needed a dedicated workspace where they could receive buyer leads in real-time, manage their inventory, handle billing, and optionally integrate the platform into their existing systems through an API. This wasn't a simple admin panel — it was a full B2B product with its own subdomain, its own business logic, and its own revenue model built around lead pricing.

subdomain routing and auth

dealer dashboard showing incoming leads with status indicators and conversion metrics

The portal lives on a dedicated subdomain, routed by Next.js middleware that inspects the hostname, validates the user's JWT, checks that the role is DEALER, and serves the correct application context. One codebase, one deployment, but an entirely different product surface depending on where you enter. The middleware handles cookie propagation across subdomains — a non-trivial detail when auth tokens need to work seamlessly as users navigate between the public marketplace and their dealer dashboard. We went through several iterations on the cookie configuration (domain, path, SameSite, Secure flags) before cross-subdomain auth worked reliably across all browsers and devices.

leads, tiers, and transparency

The lead system is the heart of the dealer portal. When a buyer on the marketplace shows interest in a car — by viewing a phone number, opening a chat, or submitting a contact form — a lead is generated and delivered to the relevant dealer in near real-time. Each lead is classified into one of three tiers: Class A (direct contact request, highest intent), Class B (phone number reveal, medium intent), and Class C (prolonged listing view, lower intent). Each class has a different price, configured globally by the platform's administrators. Dealers only pay for leads they actually receive, and every lead open is tracked — who opened it, when, from which IP. This transparency was non-negotiable for the client; dealers needed to trust the billing.

subscriptions and balance

dealer billing page showing current plan, balance, invoice history, and lead pricing by class

The subscription model layers on top of lead pricing. Dealers choose a plan that determines their monthly lead quota, which features they can access (analytics, API, priority placement), and their per-lead rates. The billing system tracks balance, generates invoices, and handles the lifecycle of plan upgrades and downgrades. When a dealer's balance runs out, lead delivery pauses — not cancels — until they top up. This required careful state management to avoid losing leads during the gap and to resume delivery cleanly once payment clears.

api keys and integrations

API keys were the feature dealers asked for most and caused the most support headaches. Larger dealers with their own CRM systems wanted to pull leads programmatically and push their inventory to the marketplace without logging into the portal. We built a key management system where dealers can generate, rotate, and revoke API keys from their dashboard. The API supports listing creation, lead export, and inventory sync. The problem is that third-party integrations break — a dealer's developer misconfigures a field mapping, their server changes IP, or they hit rate limits during a bulk import. Every broken integration lands as a support ticket on the platform team. We added detailed API error responses, a request log visible to the dealer, and a webhook testing tool to reduce the back-and-forth.

preferences, routing, and lessons

Brand and model preferences let dealers filter which leads they receive. A dealer specializing in a specific brand group doesn't want leads for other brands cluttering their inbox. The preference system lets them select brands, models, and price ranges — incoming leads are matched against these preferences before delivery. This sounds simple, but the matching logic interacts with lead classification and plan limits in ways that required careful testing. A lead that matches one dealer's preferences but not another's still needs to be delivered to someone — the fallback routing logic ensures no high-intent lead goes undelivered.

The honest lesson from the dealer portal: B2B features are deceptively complex. Every feature that seems like a single ticket — lead delivery, billing, API access — turns into a system with its own edge cases, its own failure modes, and its own user expectations. The lead pricing model alone went through three revisions before dealers felt it was fair. And the API, which we scoped as a two-week feature, generated more ongoing support work than any other part of the platform. If we built this again, we'd invest in self-service diagnostics for API integrations from the very beginning.

Stack

Frontend: Next.js 15, React 19, Tailwind CSS, TanStack Query

Auth & routing: jose (JWT), Next.js middleware (RBAC, subdomain routing)

Backend: Next.js Route Handlers, Prisma 6, PostgreSQL

Integrations: REST API with key management, webhook testing

2026, «VOSGLOS». All rights reserved.