Customer, partner & vendor portals

CPQ carries three self-service portals: one for the customers you sell to, one for the partners who sell on your behalf, and one for the vendors you buy from. Each has its own login and its own user directory, and every request is scoped to the signed-in party’s own records.

Portal	Who signs in	What it is for
Customer	A named contact at a customer account	Browsing your catalogue at their own prices, requesting quotes, tracking orders, reading invoices and contracts, raising support tickets
Partner	A user at a reseller or referral partner	Registering deals for protection, working the quotes on those deals
Vendor	A user at a supplier	Answering RFQs, acknowledging purchase orders, submitting invoices, keeping compliance documents current

Read this page before you plan a portal rollout. The customer portal is the only one you can put in front of anyone today, and only as its Android app. The partner portal signs in but nothing behind the sign-in loads, and the vendor portal cannot be opened at all. The detail is below, stated plainly, because the alternative is a customer discovering it on a live invoice screen.

Portal users are a separate identity

A portal user is not a CPQ user. Customers, partners and vendors each have their own directory record, tied to the account, partner or vendor they belong to, and none of them can see the internal application.

Customer portal users carry the most structure. Each one has a role — Admin, Buyer, Approver or Viewer — an access level, an optional approval limit, and seven individual permissions: create quotes, see pricing, see every quote on the account rather than only their own, approve quotes, place orders, view orders and view invoices. Every portal request re-reads that record, so a user who has been deactivated, has not been verified, or is locked out is refused immediately rather than at the next login.

Sign-in is deliberately strict on the customer side: only a customer portal user can authenticate, passwords are hashed, and five consecutive failures lock the account for fifteen minutes. Access tokens last an hour and refresh tokens thirty days.

The working portal sign-in is the mobile one. The customer portal authenticates at POST /api/v1/mobile/portal/auth/login and the partner portal at POST /api/v1/mobile/partner/auth/login; both issue a portal token that the portal API accepts. Signing in is as far as the partner side gets, though — see the partner portal below.

The web application carries a portal login page at /portal/login/customer, /portal/login/partner and /portal/login/vendor, but all three post to the internal staff login and receive an internal token. The customer and vendor portal APIs accept portal tokens only, and the partner API requires a real partner portal user, so a browser session cannot reach portal data whichever door it comes through. Treat the browser portals as unreleased.

There is no vendor sign-in anywhere. Nothing in CPQ creates or authenticates a vendor portal user, so the vendor portal cannot be opened by anyone — see the vendor portal below.

Managing portal users

Admin → Portal & SaaS → Portal Users is the screen for managing customer portal accounts. It lists your customer portal users with their role, access level, linked customer and status, and lets you create a user, edit one, and deactivate one. The create and edit form collects the email, username, name, role, access level, the customer account the user belongs to, an approval limit and each of the seven permissions.

One thing to know before you use it: the form has no password field and no verification step, so a user created here is saved unverified and without a password. Because the portal refuses unverified users and checks a password hash at login, a user created from this screen cannot sign in until both are set directly against the database. Partner and vendor portal users have no administration screen at all.

The customer portal

The customer portal is the largest of the three and the only one you can put in front of a customer today, as the Customer Portal Android app — see Mobile. Signed in, a customer gets their dashboard and notifications, picks from your product catalogue while raising a quote request, opens their orders with tracking and the invoice behind each one, reads their contracts and subscriptions, sees the assets and documents held against their account, and raises and answers support tickets.

Deciding on a quote from the app does not work yet. Accept Quote, Reject and Request Changes all come back with an error, because the API cannot write its record of the decision — and none of the three leaves anything behind, so the quote is untouched in the back office. Send customers the quote’s share link to accept on instead — see Quote delivery.

On the billing side the app shows the customer’s invoices with a billing summary, the payments recorded against each one, and their payment history. A customer can also submit a payment against an invoice: it is recorded pending, for your finance team to verify, and does not settle the invoice on its own. That is covered in Billing & payments.

The browser storefront

A second, browser-based customer portal exists in the web application — a storefront with a home page, catalogue, product pages, a cart, quotes, orders, invoices, contracts and support. It was built to add the pieces the app does not have: catalogue browsing at the customer’s own contracted prices, favourites, reordering a previous order in one click, requesting a contract renewal, disputing an invoice, and subscription self-service with usage, a billing preview and a prepaid-credit balance.

None of it is usable yet, and not only because of the sign-in. Behind the storefront, most of the reads are written against an older shape of the CPQ database — the contract, order and invoice lists, the invoice and order summary tiles, the product grid, the plan list, the subscription usage, billing-preview and credit views and the account-manager card all query columns the current schema does not have, so they fail rather than return empty. The writes are in the same state: reorder, contract renewal, invoice dispute and raising a quote request each fail against the live database. Plan change is the exception — its endpoint now runs and records the upgrade or downgrade as an amendment — but subscription self-service and plan change still have no route in the app at all: the screens were written but never wired into the navigation, so the working endpoint is reachable only by an API caller. The cart’s Checkout and Request Quote buttons point at addresses the app does not serve.

The parts of the storefront whose queries do hold up are the quote list and the accept and reject actions on it, favourites, product detail pages, support tickets and the FAQ — but all of them still sit behind the sign-in described above.

There is no payment in the browser storefront

The Android app’s record-a-payment form has no counterpart here. The storefront’s invoice screen shows Pay Now on each open invoice, Pay Overdue in the overdue banner and Pay All Outstanding under the payment summary, alongside View, PDF, Download Statement and Export All. None of those buttons has any handler behind it — clicking them does nothing at all. Raise dispute is the only control on that screen wired to anything, and its write does not complete against the current database either.

CPQ does have working online payment: the API issues a hosted Razorpay checkout link for an invoice and verifies the provider’s webhook signature on the way back. Nothing in the portal calls it. Until it does, take payment from your own storefront or integration using that link — see Billing & payments.

The partner portal

The partner portal was designed for deal registration. A partner registers a deal against an end customer with an opportunity name, an estimated value, an expected close date and a protection level — Standard giving ninety days of protection, Premium a hundred and eighty — and keeps editing it while it is still draft or submitted, alongside the quotes on their account.

It does not run in either channel. The Partner Hub Android app signs in, but its dashboard, deals, register-deal, quotes, orders and customers screens all query a shape of the database CPQ does not ship, so every one of them returns an error rather than a list — see Mobile. The browser partner portal is in the same state on top of the sign-in problem above: its dashboard and performance screens call addresses the partner API does not serve, training and rewards are static pages with no data behind them, and its deal list, deal detail and deal create and edit paths query the same absent shape of the deal-registration table.

The vendor portal

The vendor portal was designed as the supply-side counterpart: a dashboard of active purchase orders and upcoming deliveries, a performance scorecard with delivery and quality dimensions and improvement actions, RFQs to respond to and revise, purchase orders to acknowledge and progress, invoices to raise against a PO with a three-way match, compliance documents with expiry tracking, and a vendor-maintained catalogue with price and stock updates.

It does not run. There is no way for a vendor to sign in — no login endpoint exists and no screen creates a vendor portal user — and the purchasing side it reads from is not part of the CPQ database: there is no purchase-order table, and vendor invoices are written into the customer invoice table using columns that table does not have. The RFQ, compliance, catalogue and scorecard queries are sound against the vendor tables that do exist, but nothing can reach them.

Supplier-side purchasing is not a CPQ capability today; do not plan around the vendor portal.

Self-service quotes in the back office

Every quote a customer raises from a portal is recorded as a self-service quote alongside the quote itself, carrying where it came from, the portal user who raised it, their notes, any special instructions and a preferred delivery date, plus whether it needs internal review and whether it was later converted or abandoned. Admin → Portal & SaaS → Self-Service Quotes lists them for your team, and marking one published records that the customer has submitted it.

The neighbouring Portal Analytics screen is not usable: its calls go to an address the API does not serve, and nothing in CPQ writes portal usage events, so there is no data behind it in any case.

What ships today

Customer portal on Android, on its own sign-in, with quote requests, orders, contracts, subscriptions, assets, documents, invoices, payment history and support tickets — but not the accept-or-decline actions on a quote.
Portal user administration for customer portal users — roles, access levels and per-user permissions — with the password caveat above.
Self-service quote tracking for anything a customer raises from a portal.

Not yet: the browser storefront, the partner portal in either channel, the vendor portal in any form, card payment from a portal, and portal usage analytics.

Connects to

Mobile — the Android app the customer portal actually runs on, and the state of the Partner Hub app.
Billing & payments — the invoices, payments and hosted checkout links behind the portal’s billing screens.
Products & pricing — the catalogue a portal customer picks from when raising a quote request.
Quotes & approvals — where a portal quote request lands for your team to work.
Quote delivery — the public no-login quote link, for customers you do not want to give a portal account.