Halliday company primary sources — 2026-08-10

Classification takeaway

Halliday now clears the bar for a separate companies/ note because the useful control question is not only can a user fund an app with fiat, a wallet, or an exchange account? It is which named operator controls the easiest production path for deposit routing, provider selection, API-key issuance, quote generation, webhook truth, retry / withdrawal workflow, and cross-chain delivery defaults? Current primary materials answer that with unusual clarity: Halliday presents itself as an end-to-end deposit platform, issues API keys through its dashboard, packages a unified API across ramps / swaps / exchanges, owns the quote-confirm-status-recovery workflow, and explicitly promises provider failover, broad route coverage, and a single vendor relationship across many rails.

Primary sources reviewed

1. Official homepage — https://halliday.xyz/

   • Best high-level operator framing for the current product.
   • Calls Halliday the end-to-end deposit platform, says one Deposit button should cover cards, bank rails, exchanges, wallets, and crypto, and claims one agreement covers every rail, vendor, and market.
   • Also says routing fails over across providers automatically and advertises optimal routing by geography, payment method, and latency.

2. Documentation home — https://docs.halliday.xyz/

   • Best concise docs-level explanation of the platform boundary.
   • Says developers get a unified integration for fiat on/offramps, cross-chain swaps, and exchange payments; points developers to Halliday-issued API keys in the dashboard; and frames Halliday as the integration point even while calling the flow self-custodial.

3. API quickstart — https://docs.halliday.xyz/pages/api-quickstart

   • Strongest source for access mediation and operator workflow.
   • Says all API requests require authentication using a Halliday API key; describes the one-time-wallet / deposit-address model; and shows Halliday serving route discovery, quote, confirmation, and supported-asset endpoints from Halliday-controlled infrastructure.

4. Payment flows docs — https://docs.halliday.xyz/pages/payment-flows

   • Strongest source for the real operating sequence.
   • Shows Halliday orchestrating provider choice, quote requests, confirmation, verification prompts, checkout handoff, status polling, and recovery / withdrawal paths when flows fail.

5. Docs index (llms.txt) — https://docs.halliday.xyz/llms.txt

   • Best evidence for the breadth of the company-run API and webhook surface.
   • Lists payment quote, status, wallet-balance, recovery, withdrawal, webhook registration, signing-secret rotation, and workflow-status webhook docs under one Halliday-owned control plane.

6. Official company blog / Series A announcement — https://blog.halliday.xyz/halliday-raises-20m-series-a-led-by-a16z-crypto-to-ensure-developers-never-write-a-smart-contract-again/

   • Best source for how Halliday itself frames the company-versus-product relationship.
   • Says the company is accelerating both Workflow Protocol and the first-party product Halliday Payments, that Halliday Payments is used by 35+ clients, and that a proprietary workflow engine has powered production partner flows since 2023.

Why it belongs in the active corpus

• Useful comparison point for other company-shaped deposit / onboarding stacks where self-custodial language can obscure how much routing, retry, provider admission, and UX control still lives with one operator.
• Helpful for reasoning about the difference between an abstract workflow protocol story and the actual hosted company boundary users and integrators inherit.
• Good companion for MoonPay, Transak, Bridge, and similar one integration for many rails operator surfaces where API keys, provider failover, and webhook truth create practical leverage.