Fixing the BFF Messaging Outbound Path Bug (v0.1.78)

What Was Wrong

In the myProp BFF (Backend-for-Frontend) layer, three messaging-related route handlers were sending requests to the wrong upstream AgentOS API paths. This meant that any attempt to load messages, send a message, or respond to an offer via messaging would fail at the API boundary.

The affected file was:

src/app/api/bff/[...path]/route.ts

The Three Broken Handlers

1. messaging/messages — Fetching messages

The handler was calling ppGet(), which automatically prepends the full PeoplePortal base URL and passes pagination as a query string:

# What was being called (WRONG)
/v1/corporate/peopleportal/letmcletting/{clientName}/messaging/{userID}?offset=...

The upstream spec requires pagination as path segments, with no portal prefix:

# What the spec requires (CORRECT)
/{clientName}/messaging/notes/{userID}/{offset}/{count}/

2. messaging/message/send — Sending a message

# Wrong
/v1/corporate/peopleportal/letmcletting/{clientName}/messaging/send

# Correct
/{clientName}/messaging/notes/submit/

3. messaging/message/offer/respond — Responding to an offer

# Wrong
/v1/corporate/peopleportal/letmcletting/{clientName}/messaging/offer/respond

# Correct
/{clientName}/messaging/notes/offer/submit/

Root Cause

All three handlers incorrectly used the ppGet() helper, which is designed for PeoplePortal-namespaced endpoints and automatically prepends /v1/corporate/peopleportal/letmcletting/{clientName}. The messaging endpoints live at a different path on the upstream AgentOS client and must be called via letmcClient.get() / letmcClient.post() directly.

Additionally, the messaging/messages handler passed offset as a query parameter (?offset=N) rather than as an ordered path segment (/{offset}/{count}/) as the spec mandates.

The Fix

All three handlers were updated to use letmcClient directly with the correct path construction:

// Fetch messages
letmcClient.get(
  `/${encodePath(clientName)}/messaging/notes/${encodeURIComponent(userID)}/${offset ?? 0}/${count ?? 10}/`
);

// Send a message
letmcClient.post(
  `/${encodePath(clientName)}/messaging/notes/submit/`
);

// Respond to an offer
letmcClient.post(
  `/${encodePath(clientName)}/messaging/notes/offer/submit/`
);

Key changes:

• No ppGet() — direct letmcClient calls bypass the portal prefix.
• Path-segment pagination — offset and count are now embedded in the URL path, defaulting to 0 and 10 respectively if not provided.
• Correct endpoint names — /messaging/notes/ replaces /messaging/, and submission endpoints use /submit/ rather than /send or /respond.

Impact

This fix restores full messaging functionality for all portal users:

• Tenants and landlords can now load their message history correctly.
• Clients can send messages through the portal.
• Buyers and vendors can respond to offers via the messaging interface.

No changes were made to the UI, data models, or authentication layer. This was a pure routing fix in the BFF layer.