Skip to main content
All Docs
FeaturesmyProp (AgentOS People Portal)Updated April 4, 2026

Fixing the BFF Vendor Outbound Path — What Went Wrong and How We Fixed It

Fixing the BFF Vendor Outbound Path — What Went Wrong and How We Fixed It

Release: v0.1.88

Background

The myProp Backend-for-Frontend (BFF) layer sits between the Next.js portal and the AgentOS LetMC API. It is responsible for translating portal requests into correctly-structured outbound HTTP calls to the upstream API. Every handler in src/app/api/bff/[...path]/route.ts must construct paths that exactly match the AgentOS LetMC API specification.

The Bug

The accounts/vendor handler was calling the internal ppGet() helper like this:

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

Internally, ppGet() delegates to ppPath(), which prepends a hardcoded base segment:

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

So the final outbound request was:

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

This URL is wrong in two ways:

ProblemWhat was sentWhat the spec requires
Incorrect path prefix/v1/corporate/peopleportal/letmcletting/{clientName}/.../{clientName}/...
Wrong resource name (singular vs plural)/vendor/{vendorID}/vendors/{vendorID}

The result: every vendor lookup in the portal was returning a 404 (or an unexpected error response) from the upstream API, silently failing to surface vendor data to the client.

The Fix

The handler now bypasses ppGet() entirely and calls letmcClient directly with the canonical spec path:

letmcClient.get(`/${encodePath(clientName)}/vendors/${encodeURIComponent(vendorID)}`)
  • encodePath(clientName) — safely encodes the agency client name for use in a URL segment
  • encodeURIComponent(vendorID) — encodes the vendor ID
  • The path matches the AgentOS LetMC API spec exactly: /{clientName}/vendors/{vendorID}

Wider Impact — The ppPath() Structural Problem

This bug is not isolated to the vendor handler. The root cause is that ppPath() was designed with an incorrect base URL assumption. Any BFF handler using ppGet() or ppPost() is building the wrong outbound URL.

Contributors should audit all usages of ppGet and ppPost in the BFF route file and migrate them to direct letmcClient calls. The pattern to follow:

// ❌ Before — incorrect prefix, potentially wrong resource names
ppGet(clientName, `/someResource/${id}`)

// ✅ After — direct client call, canonical spec path
letmcClient.get(`/${encodePath(clientName)}/someResources/${encodeURIComponent(id)}`)

When auditing each handler, verify:

  1. The resource path segment matches the spec exactly (check singular vs. plural)
  2. No /v1/corporate/peopleportal/letmcletting/ prefix is present
  3. All dynamic segments are properly encoded

Summary

  • What broke: Vendor data could not be fetched — the BFF was sending requests to a non-existent URL structure.
  • Why it broke: ppPath() prepends an incorrect base prefix, and the path segment used the wrong (singular) resource name.
  • What was fixed: The accounts/vendor handler now calls letmcClient.get() directly with the correct spec-compliant path.
  • What still needs attention: All remaining ppGet / ppPost calls in the BFF should be reviewed and migrated using the same pattern.