This guide walks through integrating the Newport Exchange API (NEXAPI) into a production trading platform. We cover authentication, rate limiting, data fetching patterns, error handling, and best practices for maintaining a reliable connection to our market data feeds.
Authentication uses API keys issued through the Newport Exchange dashboard. Each key is scoped to a role (admin, reader) and can be exchanged for a short-lived JWT token via the POST /api/v1/auth/token endpoint. Tokens expire after 24 hours and should be refreshed proactively before expiry rather than reactively after a 401 response.
Rate limiting is enforced at the API gateway level. The default limit is 100 requests per minute per IP address, with higher tiers available for institutional clients. Clients should implement exponential backoff on 429 responses and cache responses locally using the Cache-Control headers provided by the API. Every response includes X-RateLimit-Remaining and X-RateLimit-Reset headers for proactive throttle management.
The currencies endpoint (GET /api/v1/currencies) returns the full active market listing with rank, price, market cap, volume, and 24-hour change. For paginated access, use the page and limit query parameters. The maximum limit is 500 rows per request. For real-time updates, we recommend polling at 60-second intervals for list data and using the WebSocket stream for individual coin price ticks.
Historical OHLCV data is available through the GET /api/v1/historical/:coin endpoint, which accepts a take parameter to limit the number of candles returned. For range-based queries, the GET /api/crypto-historical-day-data/range endpoint accepts startTime/endTime or a days parameter for convenience. Historical data is stored at daily granularity and is available for all tracked coins.
Error handling should account for three categories of failures: client errors (4xx), server errors (5xx), and network timeouts. Client errors indicate a problem with the request and should not be retried without modification. Server errors are transient and should be retried with exponential backoff. Network timeouts should trigger a reconnection with a fresh token to rule out session expiry.
For production deployments, we recommend running behind a connection pool with health checks, implementing circuit breakers to avoid cascading failures during API outages, and monitoring the X-Request-Id header on every response for distributed tracing. Our API provides a /health endpoint that reports database connectivity and cache status, suitable for load balancer health checks.