What changed in the public API.

Before funding or trading, read the user’s exchange verification state and follow the action it requests. The published contract now exposes application read/submit, session creation, business verification, business authorisation code delivery/confirmation, tax identification (TIN), enhanced due diligence (EDD), and provisioned settlement accounts. Send the company-owned userId in the query with company API-key requests. Application answers are a dictionary and UseSumsubAnswers is optional. Required nullable TIN/EDD fields must still be present: null and an omitted field are different. The request and response schemas now document the application draft, verification status and session URL. Use tier sdd or cdd for individuals, or kyb for business. To reuse approved SumSub answers, send Answers: {} with UseSumsubAnswers: true. Read provisioned addresses and bank details from settlement-accounts; submission alone does not establish approval.

• GET /api/v2/crypto-virtual-accounts/verification
• GET /api/v2/crypto-virtual-accounts/verification/application
• POST /api/v2/crypto-virtual-accounts/verification/application
• POST /api/v2/crypto-virtual-accounts/verification/session
• GET /api/v2/crypto-virtual-accounts/verification/business
• POST /api/v2/crypto-virtual-accounts/verification/business
• POST /api/v2/crypto-virtual-accounts/verification/business/authorisation/send-code
• POST /api/v2/crypto-virtual-accounts/verification/business/authorisation
• POST /api/v2/crypto-virtual-accounts/verification/tin
• POST /api/v2/crypto-virtual-accounts/verification/edd
• GET /api/v2/crypto-virtual-accounts/verification/settlement-accounts

POST /api/v2/crypto-virtual-accounts/equals-to-interlace/fund is a separate explicit-destination contract: userId is in the query, and the JSON uses IdempotencyKey, SourceBudgetId, FiatCurrency, FiatAmount, CryptoCurrency, ChainId and DestinationAddress. Its IdempotencyKey must be 8–128 characters. The original Banking-to-Crypto cards route remains available with its original UserId, BudgetId and Amount fields; do not mix the two request shapes. Crypto payouts use payout-address with Amount, Ccy and WalletAddress plus the selected network. Fiat payouts use payout-fiat and can refer to an ExternalAccountId. Register crypto destinations through crypto-address-book using lowercase name, currency, chain_id and address. Quote requests also expose InterlaceDestinationAddress and BankWithdrawal.ExternalAccountId. Trading overview adds deposits, payments, restricted_trading_currencies and fiat_funding_fees_and_limits; read current limits before presenting actions. Funding now has a typed response contract. Payouts return provider-defined JSON; do not assume a transfer ID or settlement status field without checking the returned payload.

• POST /api/v2/crypto-virtual-accounts/equals-to-interlace/fund
• POST /api/v2/crypto-virtual-accounts/equals-to-interlace
• POST /api/v2/crypto-virtual-accounts/payout-address
• POST /api/v2/crypto-virtual-accounts/payout-fiat
• POST /api/v2/crypto-virtual-accounts/crypto-address-book
• POST /api/v2/crypto-virtual-accounts/exchange/quote
• GET /api/v2/crypto-virtual-accounts/trading-overview

The new /api/v2/business-onboarding workflow complements the existing /api/v2/business/onboarding KYB application and evidence routes. Read workflow state, choose a returned tier with TierId, and use the assessment and payment actions only when appropriate for that state. Company API-key callers must supply the target business userId in the query. Checkout takes a payment UUID and TermsAccepted; invoice retrieval uses the payment UUID. Workflow status, tier selection and checkout now have response schemas; assessment returns HTTP 202 with status ASSESSMENT_PENDING and invoices return PDF content. Do not invent response properties or infer completion from HTTP success; reconcile through the workflow read endpoint. The /api/v2/admin/business-onboarding routes are separately restricted by AdminAccess in the implementation; appearing in Scalar does not grant integration API keys administrator access.

• GET /api/v2/business-onboarding
• POST /api/v2/business-onboarding/tier
• POST /api/v2/business-onboarding/assess
• POST /api/v2/business-onboarding/payments/{paymentId}/checkout
• GET /api/v2/business-onboarding/payments/{paymentId}/invoice
• GET /api/v2/business/onboarding/options

The current published MOR contract now documents optional Idempotency-Key on POST mutations. Strongly prefer one stable key per company/business action; retries must preserve method, path, query, content type and body. Completed results replay the original status/body, including partial success and errors. A changed request produces IDEMPOTENCY_KEY_CONFLICT; an unresolved operation produces IDEMPOTENCY_OUTCOME_PENDING. Reconcile pending outcomes rather than changing keys. LabelPrefix is not deduplication. Cards/page provides bounded pages (default 25, maximum 100) with stored balances. Success and business-error properties are camelCase; validation/authentication/rate-limit errors can use other formats. Merchant and assigned-card transactions expose recorded fee fields; a null fee is not zero. New outbound events cover card assignment, unassignment, load requests and KYB updates.

• GET /api/v2/mor/public/cards/page
• POST /api/v2/mor/public/cards/{cardId}/load
• POST /api/v2/mor/public/cards/{cardId}/unload
• GET /api/v2/mor/public/transactions
• POST /webhooks/outbound/mor.card.assigned
• POST /webhooks/outbound/mor.card.unassigned
• POST /webhooks/outbound/mor.kyb.updated

POST /api/v2/reporting/costs accepts From and To timestamps plus required nullable ExcludedUserIds. Its response separates currencies and includes Complete: do not treat incomplete coverage as zero cost or combine currency totals without conversion. GET users/{userId} now includes Nationality from the linked Sumsub applicant with saved-profile fallback; nationality differs from address country. Referral community policy responses add DirectRewardBps, AvailableCommunityBps and HasTopupMargin; use the returned policy instead of assuming available reward margin.

• POST /api/v2/reporting/costs
• GET /api/v2/users/{userId}

Create a personal user, start one KYC entry flow (hosted URL, SDK, reusable SumSub or manual evidence), and poll detailed KYC status. Require the relevant provider's approval, not only a generic KYC flag. Crypto cards accounts are created with the user when Crypto cards is the company default; use the /api/v2/users/create-interlace-account/{userId} repair route when needed. Banking requires its personal onboarding application and approved account/budget. Then discover a tier and card product and order the card. Never invent IDs or assume provider approvals are interchangeable.

• POST /api/v2/users
• POST /api/v2/users/{userId}/sumsub/kyc-url
• GET /api/v2/users/{userId}/kyc/detailed-status
• POST /api/v2/banking/equalsmoney-onboarding
• GET /api/v2/tiers
• GET /api/v2/tiers/card-tier/{cardTierId}
• POST /api/v2/cards

Complete user/provider onboarding first, list tiers, assign the selected tier and read its card products. BankProviderType identifies Crypto cards (1) and Banking (2) for the card providers covered here. POST /api/v2/cards requires UserId, CardTypeId and Phone. BudgetId is required for Banking; obtain it from the user's budgets rather than inventing one. Use the local returned card Id for later controls. Physical cards also require their documented delivery fields; check fee quotes and supported shipping first. Read current status after creation and never treat a pending provider action as complete.

• GET /api/v2/tiers
• POST /api/v2/users/{userId}/tier
• GET /api/v2/tiers/card-tier/{cardTierId}
• GET /api/v2/banking/users/{userId}/budgets
• POST /api/v2/cards
• GET /api/v2/cards/{cardId}

Use x-api-key from a trusted backend; the key supplies company scope. Pass the target userId when required. Dashboard JWT, /Users/Me, self-service onboarding and loyalty administration are outside the current public OpenAPI contract. Absence from this contract does not mean the dashboard feature was deleted. Outbound webhook entries describe requests Hoppa sends to your receiver; never call those paths on Hoppa.

KYC requests accept Nationality and Ssn. Effective US/USA nationality requires exactly nine SSN digits. Use the business options endpoint for canonical IndustryMain, IndustrySub and EmployeeCount values; employee count is an enum string, not a number. Banking RFI supports text responses with optional AssociatedPersonId and batches of up to ten PDF, JPEG or PNG files. Business onboarding also has compliance read, requirements, draft and submission operations.

• GET /api/v2/business/onboarding/options
• POST /api/v2/users/{userId}/kyc/equalsmoney/information
• POST /api/v2/users/{userId}/kyc/equalsmoney/documents
• POST /api/v2/business/onboarding/compliance

Read current settings and current-month usage before editing. Low-balance, failed-transaction and deposit modes are mutually exclusive on a card. Enabling requires explicit DisclaimerAccepted. Deposit mode supports USDC/USDT on Crypto cards, updates only supplied currencies, and allows each currency on only one card per user. Pass userId on every auto-top-up request. Auto Lock now has explicit enable/disable POST routes in addition to the existing PUT route.

• GET /api/v2/cards/{cardId}/auto-topup
• POST /api/v2/cards/auto-topup/low-balance
• POST /api/v2/cards/auto-topup/failed-tx
• POST /api/v2/cards/auto-topup/deposit
• POST /api/v2/cards/{cardId}/auto-lock/enable
• POST /api/v2/cards/{cardId}/auto-lock/disable

The Crypto Exchange group keeps the /api/v2/crypto-virtual-accounts prefix. Discover account IDs through trading-overview, request an exact exchange quote and accept its identifier before expiry. Crypto cards-to-Banking supports quote, initiate and confirm. Banking-to-Crypto cards requires a stable IdempotencyKey in the JSON body, uses Exchange funding and webhook-driven re-quoting, and requests user approval for moves beyond ±0.5%. Track the returned transfer and submit decisions only when its state requires them. External accounts and bank address-book routes replace assumptions based on the old settlement-account and swap-quote entries.

• GET /api/v2/crypto-virtual-accounts/trading-overview
• POST /api/v2/crypto-virtual-accounts/exchange/quote
• POST /api/v2/crypto-virtual-accounts/exchange/accept
• POST /api/v2/crypto-virtual-accounts/equals-to-interlace
• GET /api/v2/crypto-virtual-accounts/transfers/{id}
• POST /api/v2/crypto-virtual-accounts/transfers/{transferId}/decision

Read approval capabilities for the target user. Email OTP remains the baseline; native device and browser passkey approval depend on programme enablement, enrollment and client readiness. Pass userId with company API-key requests. Send the selected ApprovalDeviceId or ApprovalPasskeyId at initiation. Enroll first, verify the issued challenge through the matching approval endpoint, then complete the original payee/payout action. An active approval must be cancelled before changing to email fallback. Keep the stored quote and terms; changed or expired terms require renewed initiation and approval. A pending execution must be reconciled, not recreated.

• GET /api/v2/banking/approvals/capabilities
• POST /api/v2/banking/approvals/devices/enroll
• POST /api/v2/banking/approvals/verify
• POST /api/v2/banking/approvals/passkeys/enroll
• POST /api/v2/banking/approvals/passkeys/verify
• DELETE /api/v2/banking/approvals/{verificationToken}

All public MOR operations require MOR enablement on the API key’s company. Discover products with GET /api/v2/mor/public/cards/available before selecting CardTypeId. Simple-user creation now requires Phone. The public surface also exposes company provisioning and merchant tiers, merchant transactions, card analytics, unassignment, cancellation, assigned-user card transactions and load requests. Use these MOR routes for MOR resources; the core card DELETE guidance does not replace the MOR cancel operation.

• GET /api/v2/mor/public/cards/available
• POST /api/v2/mor/public/users
• POST /api/v2/mor/public/cards/{cardId}/unassign
• POST /api/v2/mor/public/cards/{cardId}/cancel
• POST /api/v2/mor/public/users/{userId}/cards/{cardId}/load-requests

Initiate the withdrawal, keep the returned VerificationToken and WithdrawalRequestId, and send VerificationToken with OtpCode to confirm. The contract also provides a resend endpoint. Handle RemainingAttempts, IsExpired and IsLocked; a 202 response means processing remains asynchronous. Reconcile uncertain outcomes before initiating another irreversible withdrawal.

• POST /api/v2/transfers/withdrawals/crypto
• POST /api/v2/transfers/withdrawals/crypto/confirm
• POST /api/v2/transfers/withdrawals/crypto/resend

The current contract includes programme versions/drafts/publishing, capabilities, geographic and risk policies, member and level lifecycle, links, invitations, attribution commands, community earnings, vouchers, reviews, bulk jobs and reporting. Read capabilities/options before presenting actions; do not infer that a programme supports every operation. Link edits use PATCH. Use preview/simulation operations before committing supported programme changes.

• GET /api/v2/referrals/capabilities
• GET /api/v2/referrals/options
• PATCH /api/v2/referrals/links/{linkId}
• PATCH /api/v2/users/{userId}/referrals/links/{linkId}
• POST /api/v2/referrals/programs/{programId}/simulate

Verify X-Hoppacard-Signature as lowercase-hex HMAC-SHA256 over the exact raw request body using your webhook secret. Return 2xx after durable acceptance and deduplicate webhook identifiers. Network failures, timeouts, 408, 429 and 5xx are retried up to fifteen times after the initial delivery over approximately 76 hours. Other 4xx responses are permanent failures. This update highlights fee.charged and kyc.resubmission_required; the full webhook index includes all documented events and payloads.

• POST /webhooks/outbound/fee.charged
• POST /webhooks/outbound/kyc.resubmission_required

The public contract also adds account-claim challenges and verification, account-link scan/exchange/status, price lookup and conversion, discount-code validation, Banking deposit tracking, and real-time authorization configuration, capabilities, BINs, cards, rules and decisions. Availability is programme-specific; read capabilities before enabling controls. Consult each current schema for required values and ownership constraints.

• POST /api/v2/users/account-claim/challenges
• POST /api/v2/users/account-links/scan
• GET /api/v2/prices
• GET /api/v2/authorization/capabilities
• POST /api/v2/discount-codes/validate