Customer Ref in placeOrders

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Nick JD
    Junior Member
    • Jan 2015
    • 47

    #1

    Customer Ref in placeOrders

    I'm trying to get my head around the customerRef part of placeOrders, and whether I can use it for my requirements.

    If I have multiple bots placing orders, can I pass the API a non-unique reference, so that I can identify which of my bots has made which orders?

    It's the whole "de-dupe" stuff that I do not understand.

    Optional parameter allowing the client to pass a unique string (up to 32 chars) that is used to de-dupe mistaken re-submissions. CustomerRef can contain: upper/lower chars, digits, chars : - . _ + * : ; ~ only. Please note: There is a time window associated with the de-duplication of duplicate submissions which is 60 seconds.

    eg. if I pass a reference in an order of "D", will all other orders also having the ref of "D" get bounced (for up to 60 seconds)? Or only orders containing the ref "D" in the same market, or selection?

    IOW - how does one know which bot made which order without keeping this in their own records? I'd like to eliminate the db (or any read/write) from my bots and this might be something that'll make or break this idea.

    Cheers.
  • Lopiner
    Junior Member
    • Feb 2009
    • 117

    #2
    Hi Nick JD

    I think that's a common problem with bot developers, tracking the several trades from different trading logics/bots. The customerRef unfortunately doesn't help. Some financial markets API's do use a costumer reference that is set when a trade is placed and is returned when someone retrieves the trade info, meaning that we can track trades in this way. I think betfair didn't implement something like this to avoid a read/write like you want to avoid.

    There are several alternatives to track trades. The worst one i think is dumping and retrieving the info from a DB because it costs too much. This method costs a lot but has a virtue, if your bot crashes then it can retrieve all the info on startup. Another alternative is to keep all the info in memory on objects, this is much faster to read/write but if your bot crashes then it loses track of everything. A hybrid alternative is to keep things in memory and if the bot crashes or you turn it off then it dumps the info on a DB and then retrieves on startup.

    One unorthodox method is to use the amount of the bet as a indicator of which bot it belongs. So Bot 1 will always place a bet ending in 1 like 11.01€ or 205.31€, Bot 2 ending in 2 like 94.72€. This way your bets will be very close to the amount you wish, just a few cents in difference, and when retrieving from the API you would know to where it belongs. This has some problems, you would have to think very well on how to implement this in a reliable way.


    As a side note, i always like to rely on info coming from the market/betfair/api and not from info that i keep track by putting on a DB or in memory. I think this is much more reliable.
    fooledbyabet.com

    Comment

    • Nick JD
      Junior Member
      • Jan 2015
      • 47

      #3
      I like your idea of tagging order to bots using cents or pennies, but fear a nightmare with partially-matched situations...

      Would be great if the customerRef was actually a reference made by the customer for their purposes though, wouldn't it?

      listCurrentOrders doesn't return it by the looks...

      Comment

      • LiamP
        Junior Member
        • Oct 2015
        • 284

        #4
        I keep it all in memory:

        Place order and wait for response
        Receive response and add bet data to dictionary with betId as the key

        Loop through current orders
        Look at orders in dictionary and ignore anything else

        This allows me to have multiple bots working in the same market, when it comes to greening they calculate unrealised pnl only using the bets that each bot has placed. As mentioned if the bot crashes I am stuffed but thats where proper testing comes in

        Comment

        Working...
        X