Alpaca Provider

[gbarton]

Thought I'd start a separate issue to track this. I have a few questions:

export interface IProvider {
    getMarketData(tickerId: string, timeframe: string, limit?: number, sDate?: number, eDate?: number): Promise<any>;
    getSymbolInfo(tickerId: string): Promise<ISymbolInfo>;
}

getMarketData has a return type of any, this doesnt seem right as there is a lot of expected values used from it in PineTS. Should this not be an IBar type or something?

sDate and eDate, are these expected to be seconds or ms? Since they are numbers how are you handling timezone? Is everything forced to GMT or something else? Say someone wants to start from NY open on 2025-12-01, so 9:30AM Eastern Time, what would be passed in for that? Alpaca wants an RFC-3339 compliant string so I must convert the number.

Alpaca really doesn't have much data in the way of the ISymbolInfo, the info call returns:

 {
    "id": "6b6944fb-a54a-4d2e-9a13-1565618376b0",
    "class": "us_equity", // type
    "exchange": "NASDAQ", 
    "symbol": "QQQI", //ticker
    "name": "NEOS ETF Trust NEOS Nasdaq 100 High Income ETF", //description
    "status": "active",
    "tradable": true,
    "marginable": true,
    "maintenance_margin_requirement": 30,
    "margin_requirement_long": "30",
    "margin_requirement_short": "30",
    "shortable": true,
    "easy_to_borrow": true,
    "fractionable": true,
    "attributes": [
      "fractional_eh_enabled",
      "has_options"
    ]
 }

I am prefixing ALPACA: to main_tickerid and tickerid. The other values I'm just defaulting.

[alaa-eddine]

hey @gbarton I used any there because I'm still not 100% sure about the final structure, since I only implemented binance, and I don't know if I should go with this as a standard format or have a PineTS dedicated format to which I convert all the providers.

regarding the sDate and eDate they expect ms time since unix epoch in UTC as this is the most convenient way to pass a date in JS using new Date('2025-12-12').getTime.

and it can be easily converted to RFC-3339 using new Date(sDate).toISOString()

maybe a better approach would be to accept both Date object and ms, and dynamically detect/convert the format.

if you have any suggestions/improvements don't hesitate to share them

[gbarton]

I'm a big fan of using Typescripts type safety otherwise I'd be just using js. :) So wherever possible I like strong typing and definitions.

I made a simple candle type for now that Alpaca returns into the any response, I think its reasonable and should deal with most providers fine:

export type Candle = {
  open: Number, // float
  close: Number, // float
  high: Number, // float
  low: Number, // float
  volume: Number, // float
  openTime: Number, // Integer (ms)
}

I don't see the value add of closeTime yet so I omitted it.

Next question, the factory Provider class you have right now precludes sending params to the providers. Alpaca needs keys passed so I see 2 ways. I could either bring in dotenv and look for env vars PINETS_ALPACA_KEY and PINETS_ALPACA_SECRET or extend the PineTS constructor with an options object. The constructor is already quite long so I'm leading towards putting all of those optional fields into the options obj, is that fair?

[alaa-eddine]

Yes the strong typing is a good thing, and the proposed type is good, however closeTime is important (if available on alpaca) because it's used by some internal PineScript methods related to bar states ...

regarding the Provider keys, how about something like

Provider.Alpaca.configure()
const pineTS = new PineTS(Provider.Alpaca, 'BTCUSDC', 'W', 500);

that need to be called once for providers that require special configs like API keys or anything else ?
this keeps PineTS constructor clean and can be extended in the future independently from the core