Overview

The Datafye REST and WebSocket APIs enable you to access market data and platform services from your own algorithmic trading containers. These APIs are designed for the following deployment scenarios:

• Foundry: Data Cloud Only - You run your own algo containers and use Datafye for data delivery only

• Trading: Data Cloud + Broker - You run your own algo containers with Datafye providing data delivery and broker connectivity

API URLs

The Datafye APIs provide two access methods - REST and WebSocket. The exact URLs depend on your deployment model and access method:

REST API

• Local (Standalone): http://localhost:8080/datafye-api/v1/...

• Cloud (Internal Access): http://api.rumi.local/datafye-api/v1/...

• Cloud (External Access): http://<user>-<type>-<env>-api.datafye.io/datafye-api/v1/...

The REST API provides request-response access to market data and platform services. See REST API for complete documentation.

WebSocket API

• Local (Standalone): ws://localhost:8080/datafye-ws/v1/...

• Cloud (Internal Access): ws://api.rumi.local/datafye-ws/v1/...

• Cloud (External Access): ws://<user>-<type>-<env>-api.datafye.io/datafye-ws/v1/...

The WebSocket API provides real-time streaming access to live market data. See WebSocket API for complete documentation.

Network Access

API accessibility differs based on your deployment model:

Local (Standalone) Deployments

APIs are accessible externally from your local machine:

• REST API: http://localhost:8080/datafye-api/v1/...

• WebSocket API: ws://localhost:8080/datafye-ws/v1/...

Your own containers can connect to these endpoints from your local network, making it easy to develop and test algos on your laptop.

Cloud (Distributed) Deployments

Cloud deployments support two API access models depending on where your algo containers are running:

Internal Access (Containers Running Within the Deployment)

When your containers are deployed within the same VPC/network as the Datafye deployment:

• REST API: http://api.rumi.local/datafye-api/v1/...

• WebSocket API: ws://api.rumi.local/datafye-ws/v1/...

The api.rumi.local hostname is the internal DNS name accessible only within the deployment's private network.

External Access (Containers Running Remotely)

When your containers are running outside the deployment (e.g., on your local machine, different cloud environment), you can use external DNS endpoints if the environment has been configured for external access:

• REST API: http://<user>-<type>-<env>-api.datafye.io/datafye-api/v1/...

• WebSocket API: ws://<user>-<type>-<env>-api.datafye.io/datafye-ws/v1/...

URL Format Parameters:

• <user> - The unique name assigned to you by Datafye (e.g., acme)

• <type> - Deployment type: foundry or trading

• <env> - Environment identifier (omit for production, or use dev, staging, etc.)

Examples:

Production foundry environment for customer "acme":

http://acme-foundry-api.datafye.io/datafye-api/v1/...

Development foundry environment for customer "acme":

http://acme-foundry-dev-api.datafye.io/datafye-api/v1/...

Staging trading environment for customer "acme":

http://acme-trading-staging-api.datafye.io/datafye-api/v1/...

External access is disabled by default. When you provision an environment via CLI, external URLs are not initially available. To enable external access, you must explicitly configure it:

• Self-managed deployments: Configure external access in your cloud provider's infrastructure (load balancers, DNS, security groups, etc.)

• Datafye Managed deployments: Contact your Datafye administrator to enable external access

Security Model

Datafye deployments use network-level security rather than application-level authentication. This means:

• No API keys, tokens, or authentication headers are required for any API requests

• Security is enforced entirely at the network/infrastructure layer

• The API endpoints use fixed hostnames (api.rumi.local for internal access, *.datafye.io for external access)

Internal Access Security

For internal access (containers within the deployment):

• APIs are only accessible within the private network (VPC/subnet)

• Access is controlled through network security groups and firewall rules

• Requests from outside the private network are blocked at the infrastructure layer

External Access Security

For external access (when configured):

• Security is controlled exclusively through IP allowlisting - only requests from pre-approved IP addresses or CIDR ranges can reach the endpoints

• By default, external access is NOT enabled when environments are provisioned via CLI

• IP addresses must be explicitly added to the allowlist:

  • Self-managed deployments: You configure IP allowlisting in your cloud provider's infrastructure (security groups, firewall rules, etc.)

  • Datafye Managed deployments: Contact your Datafye administrator to configure IP allowlisting

• Requests from non-allowlisted IPs are blocked at the infrastructure layer before reaching the API

• TLS/SSL encryption may be required (using https:// and wss:// protocols)

• Rate limiting may be enforced to prevent abuse

Important: External access does NOT use API keys or authentication credentials. Security is enforced entirely through IP allowlisting. If your IP address is not allowlisted, your requests will be rejected regardless of any credentials you provide.

No Authentication Required

Whether using internal or external access, your API requests never need authentication credentials:

Local deployment example:

# No authentication headers needed
curl http://localhost:8080/datafye-api/v1/stocks/reference/securities

// No authentication required in WebSocket handshake
const ws = new WebSocket('ws://localhost:8080/datafye-ws/v1/market-data');

Cloud deployment (internal access) example:

# No authentication headers needed
curl http://api.rumi.local/datafye-api/v1/stocks/reference/securities

// No authentication required in WebSocket handshake
const ws = new WebSocket('ws://api.rumi.local/datafye-ws/v1/market-data');

Cloud deployment (external access) example:

# No authentication headers needed - security is via IP allowlisting only
# Your request will succeed if your IP is allowlisted, or be blocked if not
curl http://acme-foundry-api.datafye.io/datafye-api/v1/stocks/reference/securities

// No authentication required - security is via IP allowlisting only
// Connection will succeed if your IP is allowlisted, or be blocked if not
const ws = new WebSocket('ws://acme-foundry-api.datafye.io/datafye-ws/v1/market-data');

Error Handling

Both REST and WebSocket APIs use consistent error response formats.

Common HTTP Status Codes (REST)

Success Codes:

• 200 OK - Request successful

• 201 Created - Resource created successfully

• 204 No Content - Successful request with no response body

Client Error Codes:

• 400 Bad Request - Invalid request parameters or malformed JSON

• 404 Not Found - Resource or endpoint not found

• 422 Unprocessable Entity - Request validation failed

Server Error Codes:

• 500 Internal Server Error - Unexpected server error

• 503 Service Unavailable - System temporarily unavailable

• 504 Gateway Timeout - Request timeout

Error Response Format

{
  "error": {
    "code": "INVALID_SYMBOL",
    "message": "The specified symbol was not found in the security master",
    "details": {
      "symbol": "INVALID"
    }
  }
}

Getting Started

To start using the Datafye APIs from your own containers:

1. Verify network connectivity

   • Local deployments: Ensure your containers can reach localhost:8080

   • Cloud deployments (internal): Ensure your containers can reach api.rumi.local (they must be in the same VPC/network)

   • Cloud deployments (external) (only if external access has been configured):

     • Self-managed: Configure IP allowlisting in your cloud provider's infrastructure for your IP address

     • Datafye Managed: Contact your Datafye administrator to add your IP address to the allowlist

     • Verify you can reach your <user>-<type>-<env>-api.datafye.io endpoint

     • Note: Requests from non-allowlisted IPs will result in connection timeouts or 403 Forbidden errors

2. Review the REST API documentation - Start with REST API for request-response operations

3. Explore WebSocket API - Review WebSocket API for real-time streaming

---

Last updated: 2025-10-22