Overview

Outpost Hosted Onboarding lets you onboard your existing merchants to Outpost services with minimal merchant friction. You retain full control over the merchant relationship, entry point, and checkout experience. Outpost provides the onboarding infrastructure, review workflow, and operations underneath.

Integration Flow

• You initiate - Call the Outpost API with the merchant's company data to create an onboarding application
• Merchant completes - Redirect the merchant to the Outpost-hosted onboarding UI where they fill in product-specific details and submit
• Outpost reviews - Outpost reviews the application asynchronously and approves or rejects it. You poll the application status

Listing Your Merchants

Merchants you onboard here are also readable through the partner merchant endpoints: GET /partner/api/merchants lists every merchant linked to your partner account, and GET /partner/api/merchants/{merchantId} returns one. Both are documented on the API Onboarding page. Both return merchant identity and company data, with no status. For the application status by merchant, use GET /partner/api/merchants/{merchantId}/application, which reports the lowercase set (created, submitted, approved, and so on), while the endpoints on this page return the full uppercase status below.

Base URL

All endpoints use the /partner/api prefix.

Authentication

All Partner API requests require authentication using a JWT Bearer token provided in the Authorization header.

Request Header

Authorization: Bearer <your_access_api_token>

Key Points

• Create and manage your API credentials (client ID and client secret) in the Partner Portal
• You can have up to 2 active API credentials at a time, supporting safe key rotation
• Include the JWT Bearer token in the Authorization header of every request
• Keep your API credentials secure - do not expose them in client-side code or public repositories

Returns the full application state (same structure as Get Application).

curl -X PATCH "https://api.outpostanywhere.com/partner/api/onboarding/applications/{applicationId}" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "selectedRegions": ["GB", "DE", "FR"],
    "businessDescription": "SaaS platform for finance teams",
    "storeUrls": ["https://acme.example/checkout"],
    "legalRepresentative": {
      "fullName": "Jane Doe",
      "email": "jane.doe@acme.example",
      "role": "Managing Director"
    },
    "contacts": {
      "financeContact": {
        "fullName": "Frank Smith",
        "email": "finance@acme.example",
        "role": "CFO"
      },
      "technicalContact": {
        "fullName": "Tara Jones",
        "email": "tech@acme.example",
        "role": "CTO"
      }
    }
  }' | jq

Application Status Lifecycle

Onboarding applications progress through these statuses. Regenerate Link is blocked once the application reaches APPROVED, SIGNED_BY_OUTPOST or REJECTED. APPROVED is not the end of the line: Outpost can still move an approved application back to CHANGES_REQUESTED.

Status Transitions

DRAFT
  │  merchant submits
  ▼
IN_REVIEW ──[Outpost rejects]──> REJECTED
  │  Outpost approves
  ▼
APPROVED ──[merchant signs]──> SIGNED_BY_MERCHANT
                                       │  Outpost counter-signs
                                       ▼
                               SIGNED_BY_OUTPOST

Outpost can send an application back for changes from
IN_REVIEW, APPROVED or SIGNED_BY_MERCHANT:

  CHANGES_REQUESTED ──[merchant resubmits]────> IN_REVIEW
        │
        └──[Outpost decides]──> APPROVED or REJECTED

Statuses

Who Triggers Each Transition

What You Should Do at Each Status

Data Models

Reference for the data structures used in onboarding API requests and responses.

OnboardingCompany

OnboardingAddress

PartnerContact

Used for the legal representative and for both entries under contacts.

PartnerContacts

PartnerComplianceSummary

OnboardingGmvTier

PartnerAuditResponse

Error Handling

All error responses follow a consistent structure with a category code and field-specific error details.

Error Response Format

{
  "code": "invalid_argument",
  "errors": [
    {
      "field": "company.legalName",
      "message": "required"
    }
  ]
}

Error Codes

Common Error Scenarios

Required Fields for Submission

Before the merchant can submit the application in the hosted UI, these fields must be filled (by the merchant or pre-filled by you via PATCH). The check runs only for the tor product. The field names below are the keys the error reports, which are not always the same as the request field names.

None of the four endpoints on this page returns this error. Submission happens in the hosted UI, which returns incomplete_application to the merchant. The API-mode onboarding endpoints return it too.