Fix: Tenant Active Data Now Resolves Correctly

Release: v0.1.80

What Was the Problem?

The BFF (Backend for Frontend) route accounts/tenant/active — responsible for fetching a tenant's active record from AgentOS — was calling the wrong API path.

The handler used ppGet(), a helper that automatically prepends the People Portal API prefix (/v1/corporate/peopleportal/letmcletting/). This prefix is correct for People Portal endpoints, but not for the tenant lookup endpoint, which uses a different base path.

In addition, the call appended an /active suffix that does not exist in the AgentOS API specification.

The resulting outbound request looked like this:

/v1/corporate/peopleportal/letmcletting/{clientName}/tenant/{tenantID}/active

This path would consistently return a 404 or incorrect data from AgentOS, meaning any feature relying on active tenant data was broken.

What Changed?

The handler was updated to call letmcClient.get() directly, bypassing the People Portal prefix helper and using only the correct spec-defined path:

/{clientName}/tenant/{tenantID}

This matches the AgentOS API spec exactly: GET /{clientName}/tenant/{tenantID}.

Code Change Summary

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

- const data = await ppGet(clientName, `/tenant/${encodeURIComponent(tenantID)}/active`);
+ const data = await letmcClient.get(
+   `/${encodePath(clientName)}/tenant/${encodeURIComponent(tenantID)}`
+ );

Impact

• Tenants: Active tenant data will now load correctly throughout the portal — any views or components that depend on this data (tenancy details, financial statements, etc.) will function as expected.
• Agencies: Eliminates a silent failure where the portal appeared to work but was not retrieving live tenant records from AgentOS.
• Risk: Low — only the accounts/tenant/active handler was changed. No other BFF routes are affected.