API onboarding for partners

Merchants and applications

The API splits the merchant from the application, and the split matters because the two have different lifetimes.

• A merchant is the business you are onboarding. You create it once. It is identified by a merchantId and it carries your own reference, so you can match it back to your records. Every other call in this document is scoped to a merchant you created.
• An application is a request to activate one Outpost product for that merchant in a set of regions. It has a status, a set of requirements and a review outcome. A merchant has at most one application.

Who does what

Every call is yours. The merchant never sees Outpost, and Outpost only appears at review. Nothing is sent back to you. You poll the application for the outcome.

The flow

1. 1 Create the application. POST /partner/api/onboarding/initiate with mode set to API, your own reference and the company details. This creates the merchant and the application together. To start without company details, POST /partner/api/merchants instead. See Limits to know about.
2. 2 Look up the merchantId. GET /partner/api/merchants and match on your reference. Every later call is addressed by merchantId, and initiate returns the applicationId rather than the merchantId.
3. 3 Create the application. PUT /partner/api/merchants/{merchantId}/application with one product code and the regions you want.
4. 4 Describe what the merchant sells. PATCH the same path with the trading description, store URLs and category. This is the merchant’s business model, not its legal details. Those were sent at initiate. Repeat as often as you need.
5. 5 Submit for review. POST /partner/api/merchants/{merchantId}/application/submit. Outpost reviews the application.
6. 6 Poll for the outcome. GET /partner/api/merchants/{merchantId}/application and read status, reviewMessage and requirements.errors.

Base URL

All paths on this page are relative to https://api.outpostanywhere.com. Responses omit null fields rather than returning them as null, so treat a missing key as "not set".

Get a token

# Step 1: Obtain an access token
curl -X POST \
  "https://access.outpostanywhere.com/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=$OUTPOST_CLIENT_SECRET" | jq

# Export the token (example)
# export OUTPOST_ACCESS_TOKEN="eyJhbGciOi..."

# Sample response:
# {
#   "access_token": "<JWT>",
#   "expires_in": 86400,
#   "token_type": "Bearer"
# }

Call the API

curl "https://api.outpostanywhere.com/partner/api/whoami" \
  -H "Authorization: Bearer $OUTPOST_ACCESS_TOKEN"

Cache the token server side until it expires, with a small buffer. Refresh it and retry once on a 401. Run all of this from your server — never put the client secret in a browser or a mobile app.

Scope

A token is scoped to one partner. You can only see and change merchants that were created under that partner. A merchant that belongs to another partner, or a merchant id that does not exist, returns 404 — never 403. That is deliberate: it stops anyone from probing merchant ids.

Returns the partner your token belongs to. Use it to check credentials after a rotation, and to tell your staging and production keys apart.

{
  "partnerId": "3d7c2e19-84af-4c0b-9f61-5b8e2a7d1c03",
  "name": "Example Payments"
}

Returns every region where Outpost supports at least one product. Regions that support neither Tax of Record nor Merchant of Record are left out.

200 OK

[
  {
    "id": "5f4e3d2c-1b0a-4c9d-8e7f-6a5b4c3d2e1f",
    "name": "European Union",
    "flagCode": "EU",
    "taxSupported": true,
    "morSupported": true
  },
  {
    "id": "2a9c8b7d-6e5f-4a3b-9c8d-7e6f5a4b3c2d",
    "name": "United Kingdom",
    "flagCode": "GB",
    "countryCode": "GB",
    "taxSupported": true,
    "morSupported": true
  }
]

The European Union row has no countryCode because it is not one country, so the field is left out of the response entirely.

Product codes

An application activates one product. Two codes are meaningful today, both lowercase:

• tor — Tax of Record. Outpost calculates, files and remits the merchant’s sales tax and VAT.
• mor — Merchant of Record. Outpost becomes the seller of record for the merchant’s transactions.

The API does not reject an unknown product code today. It stores whatever you send, and an unrecognised code behaves like mor : no product requirements are added. Send tor or mor, exactly as written.

This is the same endpoint the Hosted Onboarding API uses. Set mode to API and it creates the merchant, the link to your partner account and the application in one call, with the company details attached. No hosted link is generated, so the onboardingUrl in the response is not usable, so ignore it.

company is required, and this is the only endpoint that writes it. Field-by-field requirements are documented on the Hosted Onboarding page; they are identical in both modes.

curl -X POST \
  "https://api.outpostanywhere.com/partner/api/onboarding/initiate" \
  -H "Authorization: Bearer $OUTPOST_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "merchantReference": "psp-merchant-4821",
    "productCode": "tor",
    "mode": "API",
    "company": {
      "legalName": "Northwind Digital Ltd",
      "tradingName": "Northwind",
      "registrationNumber": "09123456",
      "taxId": "GB123456789",
      "jurisdiction": "GB",
      "website": "https://northwind.example",
      "gmvTier": "FROM_1M_TO_10M",
      "registeredAddress": {
        "line1": "12 Example Street",
        "line2": "Floor 3",
        "city": "London",
        "state": "Greater London",
        "postalCode": "EC1A 1AA",
        "country": "GB"
      }
    },
    "complianceSummary": {
      "verificationStatus": "verified",
      "riskLevel": "low",
      "countryOfIncorporation": "GB",
      "hasOpenComplianceFlags": false
    },
    "merchantContext": {
      "accountManager": "avery.diaz@acme-psp.example",
      "segment": "mid-market"
    }
  }'

Request body

Response 200 OK

{
  "applicationId": "3f8c1e07-5a44-4b91-9d2e-77a0c6b41e58",
  "status": "DRAFT",
  "mode": "API",
  "isExistingApplication": false,
  "onboardingUrl": "https://onboarding.outpostanywhere.com/acme-psp/onboarding?app=3f8c1e07-5a44-4b91-9d2e-77a0c6b41e58"
}

Errors

Returns the current state. This is the call you poll after submitting. It returns 404 until the application exists.

200 OK

{
  "merchantId": "9b1f4c8e-6d2a-4f7b-8e3c-1a5d0f2b7c94",
  "status": "submitted",
  "products": [
    { "code": "tor", "regions": ["EU"] }
  ],
  "requirements": {},
  "submittedAt": "2026-07-21T09:14:52.118Z"
}

Fields holding their default value are left out of the response, so an empty requirements object means nothing is due and there are no reviewer comments.

Accept any 2xx. You get 200 OK when the application already exists, which is the case in the flow above because initiate created it. You get 201 Created only when there is no application yet, which happens if you started from POST /partner/api/merchants. Either way the call replaces the region list with what you send. The product code is fixed by the first call: sending a different code afterwards returns 400.

curl -X PUT \
  "https://api.outpostanywhere.com/partner/api/merchants/{merchantId}/application" \
  -H "Authorization: Bearer $OUTPOST_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "products": [
      { "code": "tor", "regions": ["EU"] }
    ]
  }'

200 OK or 201 Created

{
  "merchantId": "9b1f4c8e-6d2a-4f7b-8e3c-1a5d0f2b7c94",
  "status": "created",
  "products": [
    { "code": "tor", "regions": ["EU"] }
  ],
  "requirements": {
    "currentlyDue": ["businessDescription", "checkoutUrl"]
  }
}

PUT only works while the status is created or changes_requested. In any other status it returns 409 invalid_status.

These fields describe how the merchant trades: what it sells, where it sells it and under which category. The legal details are separate: legal name, tax id, registration number and registered address are sent once at initiate and stay as sent.

PATCH keeps what you do not send. A field you leave out keeps its current value, and sending null also keeps it. To change a value, send the new one. PATCH leaves the product and the regions alone — use PUT for those.

curl -X PATCH \
  "https://api.outpostanywhere.com/partner/api/merchants/{merchantId}/application" \
  -H "Authorization: Bearer $OUTPOST_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "businessDescription": "Subscription meal kits sold to consumers in the EU",
    "storeUrls": ["https://shop.example.com"],
    "category": "retail"
  }'

200 OK

{
  "merchantId": "9b1f4c8e-6d2a-4f7b-8e3c-1a5d0f2b7c94",
  "status": "created",
  "products": [
    { "code": "tor", "regions": ["EU"] }
  ],
  "requirements": {}
}

Like PUT, PATCH only works in status created or changes_requested, and returns 404 if no application exists yet.

Hands the application to Outpost for review. There is no request body. On success the status becomes submitted and the response carries submittedAt.

curl -X POST \
  "https://api.outpostanywhere.com/partner/api/merchants/{merchantId}/application/submit" \
  -H "Authorization: Bearer $OUTPOST_ACCESS_TOKEN"

If anything in requirements.currentlyDue is still outstanding, the call fails with 400 incomplete_application and lists what is missing:

{
  "code": "incomplete_application",
  "errors": [
    { "field": "checkoutUrl", "message": "checkoutUrl is required" }
  ]
}

Submit is not idempotent. A second call while the application is already submitted returns 409 invalid_status. Treat that as "already submitted", not as an error to retry.

Returns every merchant linked to your partner account, as an array of id and reference. There is no pagination and no filter: the whole list comes back in one response. The list is scoped to your partner account.

[
  {
    "id": "9b1f4c8e-6d2a-4f7b-8e3c-1a5d0f2b7c94",
    "reference": "psp-merchant-4821"
  },
  {
    "id": "5c2a7f10-3b94-4de6-a1c8-7f60d3e91b25",
    "reference": "psp-merchant-4822"
  }
]

curl -X POST "https://api.outpostanywhere.com/partner/api/merchants" \
  -H "Authorization: Bearer $OUTPOST_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"reference": "psp-merchant-4821"}'

201 Created

{
  "id": "9b1f4c8e-6d2a-4f7b-8e3c-1a5d0f2b7c94",
  "reference": "psp-merchant-4821"
}

{
  "code": "duplicate_reference",
  "existingMerchantId": "9b1f4c8e-6d2a-4f7b-8e3c-1a5d0f2b7c94"
}

200 OK

{
  "id": "9b1f4c8e-6d2a-4f7b-8e3c-1a5d0f2b7c94",
  "reference": "psp-merchant-4821",
  "company": {
    "legalName": "",
    "registrationNumber": "",
    "taxId": "",
    "jurisdiction": "",
    "website": "",
    "registeredAddress": {
      "line1": "",
      "city": "",
      "postalCode": "",
      "country": ""
    }
  },
  "businessDescription": "Subscription meal kits sold to consumers in the EU",
  "storeUrls": ["https://shop.example.com"]
}

Before an application exists, only id and reference come back. The company object above shows the empty case: every field is an empty string because this merchant was created with POST /partner/api/merchants, which takes no company data. To populate it, create the merchant with initiate in API mode instead. Nothing later in this flow can fill it in.

The keys and what satisfies them

The key checkoutUrl is the one that catches people out. There is no field called checkoutUrl anywhere in the request. Send storeUrls on the PATCH and the requirement clears.

Requirements depend on the product

Only tor has product requirements. An application for mor adds none, so currentlyDue is empty from the moment the application exists.

That does not mean submit always succeeds. Submit still fails with 409 invalid_status if the application is not in created or changes_requested, and with 404 if the merchant is not linked to your partner account. Handle both cases.

What each call does in each status

In short: you can only write while the application is created or changes_requested. Everything else is read-only and answers 409.

Five statuses are the complete set

Outpost's review process has more stages than this API reports. Several of them, including the contract signing steps, all report as approved. Treat approved as the end state and do not wait for anything more granular. The mapping below is stable, so you can switch on these five values safely.

Poll the application

curl "https://api.outpostanywhere.com/partner/api/merchants/{merchantId}/application" \
  -H "Authorization: Bearer $OUTPOST_ACCESS_TOKEN"

A person reviews each application, so the outcome takes as long as it takes. Poll on a slow schedule — minutes rather than seconds — and stop once the status is approved or rejected. Watch three fields:

• status — the outcome. submitted means the review is still open.
• reviewMessage — free text from the reviewer, meant to be read by a person. Show it to whoever manages the merchant.
• requirements.errors — the specific problems, one entry per open reviewer comment. Only filled while the status is changes_requested or rejected.

Handling changes_requested

{
  "merchantId": "9b1f4c8e-6d2a-4f7b-8e3c-1a5d0f2b7c94",
  "status": "changes_requested",
  "products": [
    { "code": "tor", "regions": ["EU"] }
  ],
  "requirements": {
    "errors": [
      {
        "field": "businessDescription",
        "message": "Describe what the merchant sells, not just the industry."
      },
      {
        "field": "BUSINESS_MODEL",
        "message": "The store URL returns a holding page."
      }
    ]
  },
  "reviewMessage": "We need a little more detail before we can approve this.",
  "submittedAt": "2026-07-21T09:14:52.118Z",
  "reviewedAt": "2026-07-22T14:03:07.442Z"
}

Each entry in requirements.errors has a field and a message. When the reviewer commented on one field, field is that field’s name, such as businessDescription. When the comment is about a whole section, it is the section name in upper case, such as BUSINESS_MODEL. Treat the value as a label to display, not as a key to switch on.

The application is writable again in this status. Fix what was raised with PATCH (or PUT for the regions), then call submit again. The status goes back to submitted and submittedAt is updated. Comments a reviewer has resolved drop out of the list, so an empty errors list means nothing is outstanding.

OnboardingCompany

Sent on POST /partner/api/onboarding/initiate and returned on GET /partner/api/merchants/{merchantId}. Required fields are required at initiate; on the way back, unset fields come back as empty strings rather than being omitted.

OnboardingAddress

OnboardingGmvTier

Any other value is rejected as a malformed body, not as a field error.

PartnerComplianceSummary

Optional. Checks you have already run, stored against the application and shown to the Outpost reviewer. Every field is free text — Outpost does not parse or act on them automatically.

ApplicationRequirements

Returned as requirements on every application response. When nothing is outstanding it serialises as an empty object, so read it defensively.

Which endpoint returns what