Docs / API and agents
Supplier workspace read API
Read endpoints behind the supplier (credit team) pages: pipeline, application detail, references, messages, builder, team overview, QR and invite.
All routes need a session, answer private, no-store, and re-check role, permission and organization on each call. Several refuse in the body instead of with an HTTP error: { redirectTo: "/applications" } (go to the pipeline), { redirectTo: "/contractor/dashboard" } (not a supplier role, or an applicant on the references and messages pages, which redirect to the customer pages) or { denied: true } (supplier role without an organization or without view_pipeline).
| Method and path | Needs |
|---|---|
GET /supplier/applications, /applications/:id, /applications/:id/print | supplier role with applications.view and an organization (the detail also admits staff) |
GET /supplier/references, GET /supplier/messages | supplier role with references.view (references) or messages.view (messages); 404 otherwise |
GET /supplier/builder (builder.manage), GET /supplier/admin/overview, GET /supplier/admin/users (users.view; the users page also returns the roles catalog read from the permission matrix) | others get redirectTo: "/applications" |
GET /supplier/invite | active user of an active organization with a supplier portal role and invitations.customer |
GET /supplier/qr, GET /supplier/qr/:kind | roles eligible for QR links |
GET /supplier/find-vendors, /find-vendors/:id | session; customers get the directory of approved suppliers, each with its optional tagline and computed facts (termsGranted, medianDecisionDays only from 3 decisions in the last 12 months, referencesMin) and myApplication (the signed-in customer's own latest application to that supplier: id, status, approvedTermsDays, or null; never another customer's); the detail adds the supplier's listing (tagline, body Markdown) and facts. A supplier role gets a handoff card (vendorHandoff: true). The text is written through the listing API |
Opening an application detail that lists owners or officers (principals: name, email, SSN last four) records one pii.read audit event for that request: who looked and which application, never the values. The event is written before the data is returned, so a failed audit write fails the read.
GET /supplier/applications also returns the credit desk figures in summary, scoped to the caller's organization and read-only: lateReferences (pending references on open applications with no send or reminder for 3 days, the same interval the reminder job uses), decidedThisMonth (approved or declined since the first of the month, UTC) and oldestWaiting (the five open applications that have waited longest, with requested limit, requested terms in days and reference counts). Rows carry requestedTermsDays and approvedTermsDays (30, 60 or 90). GET /supplier/applications rows and GET /supplier/applications/:id also carry agreement (stage, label, tone, updatedAt, requestId, each signer's status, sentAt, sealedAt): the newest credit agreement request of an approved application, read in one query for the page. It is null before approval and for a caller without signatures.view. Stages: not_sent, preparing, waiting_customer, waiting_countersign, sealing, signed, needs_review, declined, expired, failed, voided. See Signatures for the request states behind them.
There is no average-time-to-decide figure on purpose: it reads as a score for credit managers.
Writes live in the Applications API, References API, Team and users API and the credit application routes in Staff operations API.