Crate fxoanda

source ·
Expand description

This is an unofficial Oanda API client. This client is still an experimental work in progress however it is reasonably functional.

The client is generated from the Oanda V20 API definitions. The current state of the client API is low-level but usable however I would like to see a more ergonomic layer developed on top.

§Installation

$ cargo add fxoanda

§Example usage

use std::env;
use fxoanda::*;

#[tokio::main]
async fn main() {
    let api_key = env::var("OANDA_KEY").expect("expected OANDA_KEY environment variable to be set");
    let api_host = env::var("OANDA_HOST").expect("expected OANDA_HOST environment variable to be set");

    let client = fxoanda::Client {
        host: String::from(api_host),
        reqwest: reqwest::Client::new(),
        authentication: String::from(api_key),
    };
    match fxoanda::GetInstrumentCandlesRequest::new()
        .with_instrument("EUR_USD".to_string())
        .with_granularity(CandlestickGranularity::H4)
        .remote(&client).await
    {
        Ok(x) => println!("OK: {:#?}", x),
        Err(e) => eprintln!("ERR: {:#?}", e),
    };
}

§Warning

Forex markets are extremely risky. Automated trading is also extremely risky. This project is extremely risky. Market conditions, news events, or software bugs can wipe out your account in an instant.

§Disclaimer

Use this project at your own risk. The maintainers of this project make no claims as to this product being fit for purpose. In fact, the maintainers of this project are telling you that you shouldn’t use this project.

Re-exports§

Modules§

Structs§

Enums§

  • DateTime header
  • The financing mode of an Account
  • The type of the Order.
  • The granularity of a candlestick
  • In the context of an Order or a Trade, defines whether the units are positive or negative.
  • The reason that the Fixed Price Order was created
  • The reason that an Account is being funded.
  • The overall behaviour of the Account regarding guaranteed Stop Loss Orders.
  • The type of an Instrument.
  • The reason that the Limit Order was initiated
  • The reason that the Market-if-touched Order was initiated
  • The reason that the Market Order was created to perform a margin closeout
  • The reason that the Market Order was created
  • The reason that an Order was cancelled.
  • The reason that an Order was filled
  • Specification of how Positions in the Account are modified when the Order is filled.
  • The current state of the Order.
  • The state to filter the requested Orders by.
  • Specification of which price component should be used when determining if an Order should be triggered and filled. This allows Orders to be triggered based on the bid, ask, mid, default (ask for buy, bid for sell) or inverse (ask for sell, bid for buy) price depending on the desired behaviour. Orders are always filled using their default price component. This feature is only provided through the REST API. Clients who choose to specify a non-default trigger condition will not see it reflected in any of OANDA’s proprietary or partner trading platforms, their transaction history or their account statements. OANDA platforms always assume that an Order’s trigger condition is set to the default value when indicating the distance from an Order’s trigger price, and will always provide the default trigger condition when creating or modifying an Order. A special restriction applies when creating a guaranteed Stop Loss Order. In this case the TriggerCondition value must either be “DEFAULT”, or the “natural” trigger side “DEFAULT” results in. So for a Stop Loss Order for a long trade valid values are “DEFAULT” and “BID”, and for short trades “DEFAULT” and “ASK” are valid.
  • The type of the Order.
  • The way that position values for an Account are calculated and aggregated.
  • The status of the Price.
  • The reason that the Stop Loss Order was initiated
  • The reason that the Stop Order was initiated
  • The reason that the Take Profit Order was initiated
  • The time-in-force of an Order. TimeInForce describes how long an Order should remain pending before being automatically cancelled by the execution system.
  • The classification of TradePLs.
  • The current state of the Trade.
  • The state to filter the Trades by
  • The reason that the Trailing Stop Loss Order was initiated
  • A filter that can be used when fetching Transactions
  • The reason that a Transaction was rejected.
  • The possible types of a Transaction
  • The day of the week to use for candlestick granularities with weekly alignment.