Setup

After installing the Gateway, this page covers advanced configuration, verification, and local testing.

Feature-Gated Builds

When building from source, you can compile only the provider you need. This reduces binary size, compile time, and dependency surface:

# Build with only Alpaca support
cargo build --release --no-default-features --features alpaca

# Build with only Binance support
cargo build --release --no-default-features --features binance

# Combine multiple providers
cargo build --release --no-default-features --features alpaca,binance

# Build with all providers (default)
cargo build --release

Feature-gated builds are useful for production deployments where you only connect to a single provider.

Provider Selection

The Gateway uses a single-provider model. At startup it scans environment variables to detect which provider credentials are configured:

1. The first provider with valid credentials is selected
2. If credentials for multiple providers are set, the others are warned and ignored
3. To switch providers, change which environment variables are set and restart the Gateway

There is no runtime provider switching — a restart is required to change providers.

Verifying the Gateway

After starting the Gateway, verify it is running correctly.

Health Check

The /metrics endpoint is the simplest health check:

curl -s http://localhost:8080/metrics | head -5

A healthy Gateway returns Prometheus-format metrics. If the endpoint does not respond, the Gateway is not running or is on a different port.

REST API

Verify provider connectivity by querying your account:

curl http://localhost:8080/v1/account

This returns account information from your configured provider. If you see an authentication error, check your provider credentials.

WebSocket

Connect to the event stream to verify real-time data:

ws://localhost:8080/v1/ws

A successful connection receives market events from your provider.

Monitoring

Prometheus Metrics

The Gateway exposes Prometheus-format metrics at /metrics on port 8080. These can be scraped by Prometheus, Grafana, Datadog, or any compatible monitoring tool.

Key metrics to watch:

• Order counts — submitted, filled, rejected, cancelled
• Latency — round-trip time from order submission to fill
• Connection status — WebSocket connection state to the provider
• Error rates — provider API errors, order rejections

Scraping Configuration

Add the Gateway to your Prometheus scrape targets:

scrape_configs:
  - job_name: 'trading-gateway'
    static_configs:
      - targets: ['localhost:8080']

OpenAPI Specification

Export the full REST API specification for code generation or API exploration:

cargo run --bin openapi-export > openapi.json

Testing Locally

Run the Gateway test suite with cargo-nextest:

# Install nextest (one-time)
cargo install cargo-nextest

# Run the full test suite
cargo nextest run --workspace --all-features

# Test a specific provider adapter
cargo nextest run -p tektii-gateway-alpaca

# Run tests with output visible
cargo nextest run --no-capture

Feature-gated testing lets you run tests for a single provider:

cargo nextest run --workspace --no-default-features --features alpaca

Running Alongside the Engine

Both the Gateway and the Tektii Engine default to port 8080 for their REST API. If you need to run both on the same machine:

Use Docker port mapping to expose the Gateway on a different host port:

docker run -d \
  -p 9080:8080 \
  -e ALPACA_API_KEY=your-key \
  -e ALPACA_API_SECRET=your-secret \
  -e ALPACA_PAPER=true \
  ghcr.io/tektii/trading-gateway:latest

Then connect your strategy to http://localhost:9080 (REST) and ws://localhost:9080/v1/ws (WebSocket).

Troubleshooting

Next Steps

• Going Live — Connect your backtested strategy to the Gateway for paper and live trading
• Trading API Concepts — Understand the unified protocol
• Connection Guide — Detailed WebSocket and REST connection patterns