Developer API reference

Public demo routes, where we publish them, need no authentication and use live data for evaluation—not static fixtures. Production access is per service and per integration.

Service hosts

Use the service guide for the product you integrate with: each page documents its production base URL, path prefix (commonly /api/v1/… on that host), and authentication. Staging or partner-specific hostnames arrive in onboarding—not every service shares one global API gateway.

Quick start

Each backend publishes its own readiness endpoint. To verify connectivity, send GET /health to the origin for the service you integrate (see that service’s guide). The example below uses ATLAS; replace the base URL with ATHENA, ARTEMIS, DIONYSUS, or another host when following a different guide.

export ATLAS_API="${ATLAS_API:-https://atlas-api.trinitytrade.io}"
curl -sS "$ATLAS_API/health"

Continue with the service guides below (ATLAS, ATHENA, DIONYSUS, ARTEMIS). For OpenAPI, IRIS web routes, HERMES, CHRONOS, and related tooling, use the Internal block in the sidebar at 127.0.0.1.

API shape and practices

• Versioned paths — On a given service, integrations should target stable /api/v1/… URLs (or the version prefix that service documents) and avoid undocumented prefixes. Versioning moves per service: not every backend will bump from v1 to v2 on the same schedule; follow release notes and the contract for each host you call.
• Specification first — Query parameters (including pagination such as page / page_size or equivalents) differ by operation. Use the service guide for the host you call; the OpenAPI catalog (Internal → OpenAPI at 127.0.0.1) aggregates many routes when you need a single document.
• Errors and limits — Handle non-2xx responses; retry transient failures and 429 with exponential backoff unless your integration guide says otherwise.

TRINITY platform

Integrate using HTTPS, JSON bodies, and each service’s documented paths and auth. Public demo routes are for evaluation where we offer them. Production access is agreed per service: authentication, allowed endpoints, quotas, error handling—then implement against the service-specific contract you pin for that integration.

Guides