The educational development center
How third-party websites and applications are actually designed, connected to the Deriv API, hosted and kept secure.
Start from what the user needs to see or do — not from the tech stack.
A typical shape: frontend, an application backend, a database, and an API integration layer.
What the user sees and interacts with — charts, forms, dashboards.
Where API tokens live, requests are made, and business logic runs, away from the browser.
Opening and maintaining a WebSocket connection to the Deriv API.
Exchanging a user's authorisation for a scoped API token.
Handling a persistent connection: reconnects, subscriptions, and message parsing.
Every integration needs a plan for dropped connections, rate limits and rejected requests.
Low-cost, limited control — fine for a static informational site.
More control, suited to bots or backends that need to run continuously.
Scalable infrastructure for larger or fast-growing services.
Vercel, Cloudflare Pages or GitHub Pages — a good fit for information sites like this one.
Every option also needs a domain and a valid SSL certificate before it's ready for real visitors.
Store tokens server-side, in environment variables — never in client-side JavaScript.
Confirm who a user is, then confirm what they're allowed to do — two separate checks.
Standard web vulnerabilities that apply to any third-party site just as much as to Deriv's own platforms.
Protect your backend from abuse, and always use encrypted (wss://) connections.
You cannot reliably hide browser developer tools from a determined user. Don't rely on obscuring client-side code to protect sensitive logic or credentials — protect them on the server instead, where the user has no access at all.
Dependencies and API versions both change over time.
Regular, tested backups of any database or user data.
Visibility into errors and unusual activity before users report them.
Every change tracked, so any regression can be traced and reversed.