DevelopersOsai website ↗
API v1
Company access / API reference

Submit Access Application

Request and response reference for POST /v1/access-applications.

POST/v1/access-applications
Authentication: Unauthenticated
Use the base URL and access configuration provided to your institution. Examples are request templates, not transaction results. Field tables focus on client fields; preserve additional metadata returned by the configured service.

Request

This entry point does not require an existing session. Applicable onboarding, origin and verification policies still apply.

Request templatecURL
curl -X POST "$OSAI_CONSOLE_BASE_URL/v1/access-applications" \
  -H "Content-Type: application/json" \
  -H "Origin: $OSAI_APP_ORIGIN" \
  -H "Idempotency-Key: <stable-operation-key>" \
  --data '{
  "legal_name": "<legal_name>",
  "company_email": "<company_email>",
  "website": "<website>",
  "country": "<country>",
  "intended_use": "<intended_use>",
  "requested_corridors": [
    "<value>"
  ],
  "consent_version": "<consent_version>"
}'

Parameters

NameLocationRequirementDescription
Originheader · stringRequiredUse the value defined for this resource.
Idempotency-Keyheader · stringRequiredUse the value defined for this resource.

Request body

Send JSON with Content-Type: application/json. Nested field names identify their parent object; required markers apply within that object. Replace template values using the relevant resource and configured instrument rules.

FieldTypeDescription & constraints
legal_nameRequired in parent objectstringDefined by the resource contract.
company_emailRequired in parent objectstringDefined by the resource contract.
websiteRequired in parent objectstringuriDefined by the resource contract.
countryRequired in parent objectstringDefined by the resource contract.Pattern: ^[A-Z]{2}$
intended_useRequired in parent objectstringDefined by the resource contract.
requested_corridorsRequired in parent objectarrayDefined by the resource contract.
consent_versionRequired in parent objectstringDefined by the resource contract.

Responses

Inspect HTTP status before parsing a body. These tables describe client response fields rather than invented successful transaction payloads.

202 · HTTP 202 response
FieldTypeDescription & constraints
statusRequired in parent objectstringDefined by the resource contract.Values: RECEIVED, MAILBOX_VERIFIED_REVIEW_PENDING
400 · Invalid bounded request

No client body fields are defined for this response.

401 · Authentication required

No client body fields are defined for this response.

403 · Staff scope, MFA, CSRF, domain or verification denied

No client body fields are defined for this response.

409 · Version, slug or idempotency conflict

No client body fields are defined for this response.

503 · Unconfigured policy, unavailable owner or unknown outcome

No client body fields are defined for this response.

Retries & recovery

Keep the original request identifiers and any required idempotency key. A timeout does not establish failure. Read the original resource or command before another financial write; use expected versions for concurrent changes.

16 suggested pages

Get startedIntroductionIntegrate institutional FX and stablecoin trading with quotes, orders, market data, account records and settlement reporting.Get startedQuickstartMake an authenticated read, request a quote and follow an instruction without losing its original references.Get startedAuthenticationUse the correct authentication scheme for API credentials, Console sessions and market-data feeds.Get startedErrorsDistinguish invalid inputs, denied access, conflicts, rate limits and uncertain outcomes.Get startedRate limitsUse response headers, bounded concurrency and backoff rather than repeated bursts.Get startedAmounts & precisionKeep minor-unit money, fixed-point FX rates and instrument-scaled quantities exact.Get startedPagination & recoveryUse each resource’s pagination model and preserve stable recovery checkpoints.Financial workflowsQuotes & acceptanceRequest explicit FX economics, review conditions and retain accepted terms.Financial workflowsTrade lifecycleTrack funding, execution and settlement as distinct business transitions.Financial workflowsBalances & transactionsRead institutional financial positions and reconcile movements by currency.Financial workflowsBeneficiariesRegister beneficiaries and coordinate their institutional approval lifecycle.Financial workflowsCredential managementCreate, inspect, rotate and revoke application credentials without exposing secrets.Events & reliabilityIdempotencyPrevent duplicate financial effects across retries and uncertain outcomes.Events & reliabilityWebhooks & verificationVerify deliveries, persist original events and make downstream processing idempotent.Events & reliabilityEvent payloadsUnderstand the customer event envelope and business transitions behind subscriptions.Events & reliabilityDelivery retries & replayRepair webhook delivery without creating a second business event.