Fixing the BFF Vendor Outbound Path — What Went Wrong and What to Check

This post accompanies the v0.1.82 release and explains the root cause of the vendor API path bug, how it was fixed, and what developers should audit in related BFF handlers.

What Broke

When a client portal page requested vendor account details, the Backend-for-Frontend (BFF) layer was silently sending requests to the wrong URL. The accounts/vendor handler in src/app/api/bff/[...path]/route.ts called:

ppGet(clientName, `/vendor/${vendorID}`)

Internally, the ppGet helper delegates path construction to ppPath(). That function prepends a hardcoded stem:

/v1/corporate/peopleportal/letmcletting/{clientName}

so the outbound request became:

GET /v1/corporate/peopleportal/letmcletting/{clientName}/vendor/{vendorID}

The AgentOS LETMC API does not have that prefix, and the resource name is plural. The correct path per the API specification is:

GET /{clientName}/vendors/{vendorID}

Because the path was wrong, the API returned a 404 (or similar error), and vendor data was unavailable to any portal user whose agency uses the vendor account flow.

The Fix

Rather than patching ppPath() (which would risk breaking other callers), the handler was updated to call the LETMC HTTP client directly with the correctly formed path:

// Correct — calls AgentOS LETMC API at /{clientName}/vendors/{vendorID}
letmcClient.get(`/${encodePath(clientName)}/vendors/${encodeURIComponent(vendorID)}`)

Both the path prefix problem and the singular/plural resource name problem are resolved in a single change.

Why This Happened

ppPath() was originally written for a different target base URL — likely an internal proxy or an older API gateway that expected the /v1/corporate/peopleportal/letmcletting/{clientName} prefix. The AgentOS LETMC API paths, however, follow a simpler convention:

/{clientName}/{resource}/...

When the BFF was extended to call LETMC endpoints directly, the ppGet/ppPost wrappers were reused without accounting for this difference, silently producing the wrong URLs.

What You Should Audit

If you maintain or extend BFF route handlers, check every call to ppGet and ppPost in src/app/api/bff/[...path]/route.ts and related files. For each one, verify:

Question	Expected answer
Does the target endpoint live at /{clientName}/...?	Use letmcClient.get/post directly
Does ppPath() add a prefix the target API does not expect?	Yes — do not use ppGet/ppPost for LETMC endpoints
Is the resource name in the path plural (e.g. vendors, landlords)?	Check against the AgentOS spec

Quick grep to find all affected call sites

grep -rn 'ppGet\|ppPost' src/app/api/bff/

For each result, cross-reference the path argument against the AgentOS LETMC API specification to confirm the full URL that will be built is correct.

Correct Pattern for LETMC API Calls in the BFF

import { letmcClient } from '@/lib/letmc-client'
import { encodePath } from '@/lib/encode'

// GET /{clientName}/vendors/{vendorID}
const vendor = await letmcClient.get(
  `/${encodePath(clientName)}/vendors/${encodeURIComponent(vendorID)}`
)

// GET /{clientName}/landlords/{landlordID}
const landlord = await letmcClient.get(
  `/${encodePath(clientName)}/landlords/${encodeURIComponent(landlordID)}`
)

Always use encodePath for the clientName segment and encodeURIComponent for ID segments to avoid path injection issues.

Impact

• Affected flow: Vendor account detail lookups in the portal.
• Symptom: Vendor data failed to load; the BFF returned an upstream error.
• Fixed in: v0.1.82.
• No data loss or security impact — the wrong path produced an error rather than returning incorrect data.