Required Third-Party Services
To run end to end, the platform relies on a set of external services. This page is a procurement checklist: read it before you start so you know what needs to be provisioned and who owns each piece. It is intentionally non-technical — it tells you what and why, not how.
Two audiences: most of these are operator-provisioned (the team running the platform sets them up). As an integrator, you mainly need API credentials and network access — the bottom of this page summarizes exactly what falls to you.
External integrations
| Service | Why it's needed | Common options | Required? |
|---|---|---|---|
| Blockchain RPC endpoint | To deploy contracts, read state, estimate gas, and broadcast transactions on an EVM network. | A node provider or self-hosted node for the target chain (mainnet / L2 / testnet). | Required |
| Block explorer API | Transaction verification and contract/ABI lookups. | An Etherscan-style explorer API for the target chain. | Required |
| Custody / key management | Secure key storage and transaction signing — the platform talks to this like a third party and never holds keys itself. | Custody service backed by MPC, HSM (incl. domestic/bank-grade), and/or Cloud KMS. | Required |
| Email delivery | Transactional notifications to users and operators. | A transactional email provider, or an SMTP server. | Required |
| SMS / push (optional) | Out-of-band user notifications. | Any SMS gateway or push provider. | Optional |
| Object storage | Storing documents, media, and branding assets. | An S3-compatible store (cloud object storage). | Required |
| Price / oracle feed | Market and asset pricing for valuation and exchange rates. | A market-data / fund-pricing source and/or on-chain oracle. | Required if pricing features are used |
| AI assistance (optional) | Tokenization suggestions and integrator assistants. | An LLM provider. | Optional |
Platform infrastructure (operator-provisioned)
These are the building blocks the operator stands up to run the platform. They are listed so you understand the deployment shape — you do not integrate against them directly.
| Component | Role |
|---|---|
| Primary database | System of record for nodes, tokens, categories, fees, users. |
| Cache | Fast access for sessions, tokens, and usage tracking. |
| Message broker | Asynchronous background processing (e.g. migrations, on-chain follow-ups). |
| Observability (optional) | Distributed tracing and error reporting for operations. |
Choosing a custody / key provider
Because custody is provider-independent, the choice here is driven by your compliance and risk profile rather than by the platform:
- Data-residency or local-certification requirements → a domestic/national HSM.
- Bank-grade / PCI / FIPS 140-2 L3 needs → an enterprise HSM.
- Cloud-native, distributed operation with no single point of failure → MPC.
- Fast setup and hybrid backup → Cloud KMS.
- Maximum compromise resistance → multi-provider signing for high-value flows.
You can mix these (e.g. hot wallets on MPC, cold storage on hardware) and phase providers in over time without downtime.
What falls to you as an integrator
For a pure API integration, your checklist is short:
- API credentials — client credentials for OAuth2 (and, if required, an mTLS client certificate). See Security & Access.
- Network access — your calling system's IP ranges allow-listed with the operator.
- A webhook endpoint — a reachable HTTPS URL to receive asynchronous transaction and migration callbacks.
- Agreement on environment — test vs. production base URLs and the target blockchain network.
Everything else in the tables above is provisioned and operated on the platform side. If you are also standing up your own deployment of the platform, treat the full list as your provisioning plan.