Pathway’s client credentials request only
applications:write. The merchant’s consent screen requests applications:read applications:write. Nothing else under the merchant’s account is requested or read.
The application request
Pathway sends one request per referral, when the merchant clicks Apply on the referral page or a firm user clicks Send to Ramp with a consent attestation. Both are recorded on the referral with who did it and from where. The body follows Ramp’s schema.applicant.first_name, last_name, and email are always present. Everything else is included only when Pathway holds it: business with its address and incorporation details, controlling_officer and beneficial_owners, financial_details, manual_bank_account, ownership_acknowledgement, and application_type. oauth_authorize_params carries Pathway’s registered redirect_uri and a state value private to the referral, held only by Pathway’s database and Ramp.
Ramp returns 202 with no body, and Pathway logs the x-ramp-request-id header. Ramp keys the business on applicant.email, so a repeat request re-sends the invitation; Pathway allows one resend per ten minutes. The email is set by the referring firm inside Pathway and locked after the first send. The public link shows it masked, cannot change it, and can start the application only once; resends are made from inside Pathway, and every link stops working while the org has Ramp turned off.
Pathway allows one sent referral per applicant.email across all organizations, because Ramp credits the first sender. The send takes a transaction-scoped Postgres advisory lock on the email, checks for another sent referral, and answers 409 before calling Ramp. Drafts reserve nothing. A request Ramp refuses is recorded on the referral with Ramp’s message, and Ramp’s x-trace-id is kept in Pathway’s server logs.
The OAuth handoff
After the merchant sets a password, Ramp shows the consent screen and redirects to Pathway’sredirect_uri with code and state. Pathway looks up the referral by state, exchanges the code at POST /developer/v1/token with grant_type=authorization_code, stores the access and refresh tokens on the referral, reads the application once, and redirects the merchant to Ramp’s sign-in with their email prefilled. If anything after the lookup fails, it is logged on the referral and the merchant is still sent to Ramp.
Both tokens are stored encrypted at rest with a key held only by the API. Access tokens are refreshed with grant_type=refresh_token shortly before expiry. If Ramp rejects the refresh token, Pathway clears the grant and stops reading that referral. The merchant’s application at Ramp is unaffected.
Status
GET /developer/v1/applications under the merchant’s grant returns that business’s application. Pathway keeps its id and status and maps the status onto the referral:
Before the first read, the referral is Ready to share or Invite sent, both set by Pathway. Pathway reads every referral with a grant every 15 minutes until the status is
APPROVED, REJECTED, or WITHDRAWN, and on demand from Check status. An unchanged status adds nothing to the referral’s log. The first grant a referral receives is the one it keeps; a later consent for the same referral is ignored.
Data
Prefill can include an owner’s date of birth, SSN last four, home address, and a bank account with its balance. Pathway sends it only on an explicit Apply or Send to Ramp, records who clicked, and shows the merchant a consent line naming both the referring firm and LendPathway.
Environments
The sandbox sends real invitation emails and runs Ramp’s real application form, but nothing is underwritten and no card is issued. The Ramp page in Pathway shows which environment it is connected to.