title: Applications source_url: /developer-api/v1/applications summary: Pre-fill a Ramp application on behalf of a new business as a Ramp partner. Ramp emails the applicant, they finish sign-up in the Ramp UI, and your platform can optionally obtain API access to the new business through OAuth. content: Pre-fill a Ramp application on behalf of a new business as a Ramp partner. Ramp emails the applicant, they finish sign-up in the Ramp UI, and your platform can optionally obtain API access to the new business through OAuth. Cross-business client access required Creating an application requires a client that is permitted to access businesses other than its own. Clients restricted to their own business cannot use the create endpoint. Review Partner Integrations to learn about partnership requirements and production access. A partner-led customer onboarding flow: Your platform POSTs an application with the applicant's information. Ramp emails the applicant a sign-up invite. The applicant accepts the invite and (optionally) grants your app OAuth scopes on the new business. The applicant completes and submits the application in the Ramp UI. Ramp reviews; your platform receives status updates via webhook. The API creates and pre-fills the application but does not submit it — the applicant always finalizes submission in the Ramp UI. Required: A Ramp app registered in the Ramp Developer Console with the Client Credentials grant type enabled. The POST endpoint takes no scopes; reading status afterward requires applications:read granted on the new business via the Authorization Code flow. Recommended: Read Partner Integrations for the broader partnership context, listing requirements, and security expectations. Prerequisites: To capture the applicant's OAuth grant, configure both applications:read and applications:write as allowed scopes and register an HTTPS redirect_uri. Ramp requests both scopes for this application consent flow, even though reading the resulting application only requires applications:read. Three actors: your platform, Ramp, and the applicant. Ramp brokers the email handoff and, when requested, the OAuth grant. Implementation POST /developer/v1/applications with the applicant's information. Authenticate with Client Credentials; the endpoint takes no scopes. The response is 202 Accepted with no body — Ramp creates the business and queues the invite asynchronously. The request must include an applicant object with email, first_name, and last_name. You can also provide: application_type: RAMP_SUITE (the default) or BILL_PAY_ONLY. business, financial_details, controlling_officer, and beneficial_owners to pre-fill the application. ownership_acknowledgement to confirm whether all owners with at least 25% ownership are included. manual_bank_account to provide an external bank account for underwriting. oauth_authorize_params to request OAuth authorization after the applicant accepts the invite. The endpoint is designed to be safely retried: If the applicant's email doesn't exist in Ramp, a new business and application are created. If the email already exists and the business is still in the application stage, Ramp re-sends the invitation email. If the business is already approved, the request is a no-op. Include oauth_authorize_params in the POST body to route the applicant through your app's OAuth consent screen after they accept the invite: After sign-up, Ramp shows the applicant your app's consent screen requesting applications:read and applications:write. On approval, Ramp redirects to your redirect_uri with code and state. Exchange the code for an access token per the Authorization Code flow. Without oauth_authorize_params, the applicant is sent directly to the Ramp application after accepting the invite — no consent screen. You can prompt them to authorize the connection later. redirect_uri requirements The redirect_uri must be registered in your app's configuration in the Ramp Developer Console and must use HTTPS (or localhost for development). After the OAuth handoff — or at any point after submitting — link the applicant to Ramp's sign-in page to finish their application: The email query parameter is optional. When provided, it auto-populates the email field on the sign-in page. Invite must be accepted first The applicant won't be able to sign in until they've accepted the email invite from Ramp. If they haven't received or accepted the invite yet, direct them to check their inbox first. Applications walk a status enum: Status Description applications.status_updated trigger STARTED Application has been started but has not been submitted for review. No IN_REVIEW Application has been submitted and is under review by Ramp. Yes, when the applicant submits the application. FOLLOW_UPS_REQUIRED Ramp needs additional information from the applicant. APPROVED Application has been approved — the business can start using Ramp. Yes, when Ramp approves the application. REJECTED Application has been rejected. Yes, when Ramp rejects the application. WITHDRAWN Application has been withdrawn by the applicant. Call GET /developer/v1/applications to fetch the current application and its status. Each business can have only one active financing application, so this endpoint returns a single application object, not a list. It requires the applications:read scope obtained via the Authorization Code flow in step 2. Subscribe to the applications.status_updated webhook so your platform reacts in real time when an application enters IN_REVIEW, APPROVED, or REJECTED. Other statuses can be returned by GET /developer/v1/applications but don't currently trigger this webhook. Payload: The event includes the new status in object.status. When you receive the event, call GET /developer/v1/applications to fetch the full application details. Subscribing to this event requires the applications:read scope. See Webhooks for subscription and signature verification. Partner approval. Production listing on Ramp's Integrations page requires going through the partner launch checklist. See Partner Integrations. Webhook reliability. Verify webhook signatures and treat the status-updated event as the canonical trigger for downstream workflows; the GET endpoint is the source of truth on read. Error recovery. The POST endpoint is idempotent on applicant email — safe to retry. Retry 5xx responses and rate-limit responses after an appropriate delay. Resolve other 4xx errors before you retry. Partner Integrations — partner program: pricing, listing, security, support expectations. Applications — submit applications, fetch status. Authorization — Client Credentials for POST, Authorization Code for read after the applicant grants applications:read. Webhooks — subscribe to applications.status_updated for real-time status changes.