Integrations

Veytics is a thin proxy in front of several external services. This section documents what connects to what, what to expect from each, and how to operate the boundary safely.

System

• Architecture — backend, frontend, database, cache, websocket, and how data flows from upstream providers to the user's screen. Read first if you're contributing or debugging operationally.

Data providers

Five upstream data sources, all proxied through the backend so API tokens never reach the client:

• Data providers — Finnhub, EODHD, OpenSky, AISstream.io, Cesium Ion. What each one delivers, where it's wired, and which env var configures it.
• API keys — concrete signup steps, free-tier vs paid notes, env-var checklist per provider.
• Data delays & limits — coverage gaps, free-tier delays, polling intervals, and AI Chat token caps. Critical reading before you trust an Veytics number.

Billing

• Stripe billing — how subscriptions are managed, what the webhook does, and how to debug a desync.

Deployment

• Self-hosting — running Veytics on your own infrastructure. Required env vars, dependencies, and the supported deployment shapes.

Boundaries Veytics enforces

Two non-negotiable rules in CLAUDE.md:

1. All upstream calls go through the backend. The frontend never talks to Finnhub, EODHD, OpenSky, AISstream.io, or Stripe directly — only the backend does. This keeps API keys server-side.
2. Environment variables only. API keys, DB credentials, JWT secrets are never hardcoded, never committed, never logged. Anything ending in _KEY, _PASSWORD, or _SECRET is read from os.environ at request time.

If you spot a violation in code review or your own fork, treat it as a P0 incident: rotate the credential upstream, scrub it from history, and move it behind an env var.

Related

• Quick Start — the env-var checklist for first-run setup
• Account & billing — user-facing billing flow
• OSINT operational security — defending the credentials boundary in adversarial conditions