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

Under the Hood: Fixing the Payment Requests Endpoint in v0.1.51

Under the Hood: Fixing the Payment Requests Endpoint in v0.1.51

Version: 0.1.51
Affected area: Payment Requests — src/lib/letmc/payment-request.ts

Background

As part of the myProp rebuild from a Vue/Vuex + Amplify Lambda BFF architecture to a modern tRPC-based stack, a routing discrepancy was discovered in the payment requests flow. This post explains what was found, why it matters, and what needs to happen next.


The Problem

Original Architecture

In the original app, the Vuex store dispatched a POST request to:

POST /accounts/payment-requests

This hit an Amplify API Gateway → Lambda BFF, which handled authentication, constructed the AgentOS call, and returned a standardised envelope:

{
  "success": "Request Succeeded!",
  "data": { ... },
  "status": "200",
  "url": "/accounts"
}

The Lambda BFF internally called the correct AgentOS endpoint:

/{clientName}/payments/requests/{personID}?api_key={API_KEY}

Rebuilt Architecture

The rebuilt app replaces the Amplify Lambda BFF with tRPC via paymentRequestRouter. However, two issues were introduced:

  1. Wrong AgentOS path: The tRPC handler was calling:

    /v3/{shortName}/lettings/tenants/{id}/paymentrequests
    

    instead of the correct:

    /{clientName}/payments/requests/{personID}?api_key={API_KEY}
    
  2. BFF envelope not replicated: The original { success, data, status, url } response shape was dropped, which breaks any consumer expecting that contract.


Why This Matters

  • Incorrect AgentOS path means payment requests are sent to a non-existent or wrong endpoint, causing silent failures or unexpected errors for tenants attempting to make payment requests through the portal.
  • Missing envelope shape breaks any existing frontend code or third-party integration that parses the success, status, or url fields from the response.

The Fix

1. Correct the AgentOS Endpoint

In src/lib/letmc/payment-request.ts, update the AgentOS API call to use the correct path:

// ❌ Before (incorrect)
const url = `/v3/${shortName}/lettings/tenants/${id}/paymentrequests`;

// ✅ After (correct)
const url = `/${clientName}/payments/requests/${personID}?api_key=${API_KEY}`;

2. Consumer Migration (BFF Envelope)

Since tRPC replaces the Amplify API Gateway, the BFF envelope shape ({ success, data, status, url }) is not required in the new architecture — as long as all consumers are updated to use the tRPC client interface instead of parsing raw HTTP responses.

Teams with integrations against the original /accounts/payment-requests POST endpoint should:

  1. Identify all call sites referencing the old endpoint or parsing the old envelope shape.
  2. Migrate those calls to use the tRPC paymentRequestRouter client.
  3. Update response handling to use the tRPC response structure directly.

Checklist

  • Update src/lib/letmc/payment-request.ts — correct AgentOS path to /{clientName}/payments/requests/{personID}?api_key={API_KEY}
  • Audit all frontend consumers of /accounts/payment-requests (POST)
  • Migrate consumers to the tRPC paymentRequestRouter interface
  • Remove any response parsing logic that expects the legacy BFF envelope shape
  • Test end-to-end: tenant submits a payment request → correct AgentOS endpoint is called → success response returned

Architecture Reference

LayerOriginalRebuilt
Frontend callVuex action → POST /accounts/payment-requeststRPC client → paymentRequestRouter
MiddlewareAmplify Lambda BFFtRPC server handler
AgentOS path/{clientName}/payments/requests/{personID}?api_key=⚠️ Was incorrect — now corrected
Response shape{ success, data, status, url }tRPC response object