We are proud to announce that Bondora API (Application Program Interface) Sandbox environment is up and running. People interested in the API now can access the documentation and start implementing their client applications. The Sandbox is a test environment that emulates the behaviour of the production API. This means that the auctions are not real and making bids into auctions is not causing any actual bids or transactions. The Sandbox environment can also change a bit, because the development is still in progress. The changes should not cause any breaking changes though.

API is an additional interface for accessing the functionality of Bondora platform without the user interface (UI). It’s an alternative to Bondora web UI and is to be accessed programmatically via custom client application. Every investor can create their own implementation of the client application. You can choose any programming language and platform. You could even create a browser plugin and have the UI look the way you want and show the data that you are interested in. We are expecting lots of different client application implementations that other investors can also use. More proficient investors can create automated bidders that request auctions, filter them by predefined parameters and automatically make bids into them.

API is implemented as a RESTful web service, meaning that all the communication is sent via HTTP, like accessing any website. For accessing different API resources (aka uri like https://api.bondora.com), the user must be authenticated prior with his/her username and password. On authentication the API responds with unique token that is generated for the user and is valid until provided date. When accessing API resources (requesting data), the user must provide the issued API token for every request. The token must be set to the request Authorization header as „Token “.

For more information you are welcome to check the API site where you can find more detailed description of the API and a technical reference documentation for all the API resources.

77 responses to “Platfrom Update: Bondora API Sandbox is Up and Running!”

  1. How the bidding system works?

    API allows to place a bid with Amount and also with MinAmount. Later, when i ask for all the bids, i see RequestedBidAmount, RequestedBidMinimumLimit and also ActualBidAmount, that at first at least is 0.

    There’s also BidProcessedDate and API specs describe it as “when bid is placed by autobidder”.

    So how the bidding really works? Is it like registering a bid and then your own autobidder starts to use that data? Is that autobidder working in sandbox environment?

    Thank you!

    • All bids made through API are collected to “Bid Pool” and executed periodically with the passive investment. The exact algorithm for bids ordering is still in development with the new “Passive Investing” platform update.

      The Sandbox bidding is currently not making any bids into auctions. The bids are just collected into Bid Pool. It is a test environment for validating your API implementation against and not live system. But, we have plans to add some bidding simulation logic to the API bids, so that you would get more dynamic results when bidding using the Sandbox API.

    • Very cool, thank you.

      When the autobidder’s algorithm is more solid, let us know, how the it works exactly. :)

      Is there also going to be a “cancelBid” functionality? In case the autobidder hasn’t yet run the bid through, it might be nice to have this ability to remove the bid from pool.

    • Glad to be helpful.

      Bid canceling functionality is in development backlog. Good to know that users are interested in it. As soon as the main functionality is ready and stable, we will start to develop additional functionality.

    • Can you give us some estimated time it will stay in Bid Pool? The problem I see is another case of blocking users funds without knowing if the Bid has passed and been accepted in auction.

      Anyway there should be unique ID for each Bid so we can ask through API about the state of Bid (and probably to cancel them).

    • Bids in a pool do not block user funds. These are basically requests for bids that user wants to make into auctions. When system starts processing bids from the pool, then the system will check if the user has enough funds and if the auction has available unfunded amount. Only after that actual bid into auction is made and funds are reserved.

    • For how long does bid stay in Pool?

      I don’t know if you are aware of it but it doesn’t matter if pool blocks funds or not…

      When I decide to make bid on something I just need to take care of funds reservation myself if your system won’t do it…So I need to block my funds until I know result of the bid.

    • There’s also another interesting thing: In fact, you can put multiple bids on the same loan.
      In a sense i feel, it’s a good thing to have. This way, instead of putting 25€ in the loan, i can put 5×5€ into the loan. Then later on i can sell 2×5€ on the secondary market and keep 3×5€ of the loan.

      Can you confirm, this is the intended behavior? Or it’s a “bug”? (I would love to have that bug :) )

    • The intended behavior was to be able to invest into multiple loans by making only one request. But, yes, you can also invest multiple times into same loan. It’s not limited by any ways.

    • Sorry, but only intended thing I see is that you don’t allow us to see results of bidding immediately and instead offer some blackbox called BidPool that allows you to prioritize bids on your own.

      This is not transparent way to do it.

  2. Currently bids are processed every 2 hours. The bids are ordered by bid time. The period and prioritizing will change in the future and we will notify users about the changes.

    The rules, how the bids are processed from the bid pool (prioritizing), are still open and thus we cannot further comment on that. We will make the decision rules public when the rules are ready and added to the bid processing.

    • You have announced API, that “gives investors a lot of flexibility”… We though this will be transparent and open system. After this discussion what we see is you are giving us closed blackbox.

      There is a lot more that you don’t want to comment now. Now we see why…

    • What I don’t understand is if you really want 3rd party to offer services on top of your API… Do you think anybody will invest time to development of tools for clients just to find that in some time Bondora with one click gave their service zero priority in bid pool?

      We know that you offer 1% of invested amount to agent that will negotiate and find funds willing to invest.

      So these hedge funds will be the ones getting priority. Tell us – why waste our time when you are showing us that you don’t want to be transparent, don’t want fair rules for all parties and want become blackbox for VIP clients so you can gather comissions?

    • Looks like they like us to test/bugfix API that will be provided to VIP’s with less bugs after our test

    • 3rd party services (eg lendingrobot) usually disclose priority policy to show users that it is fair to all their users and that everybody has chance to invest in best loans.

      With Bondora 3rd parties can practically throw their policies to trash as (they cannot enforce their policy because) Bondora does their own prioritizing.

    • Wow, this is an eye opener. Thanks for this post, n3tcarlos.

      Bondora has likely become a whor* of institutional money. Retail Investors, move on.

  3. Hi!

    I have looked a bit more into actions information and see that there’s some information missing really. For example, there’s income information but nothing about expenses.

    In addition, it would be nice, if there would be a list of auction ids, that the same client has applied before. And those ids can be used to retrieve information of those historical loans too.

    Thank you.

    • Actually this is why I would really like to see current “Dataset Export” feature (both public and private) available through the API. This way you could cache the whole Loan dataset and wouldn’t need to retrieve each row separately.

    • Well, if it would also include filtering option based on dates or last known loan to you, then we could write incremental loan list update, which would be more efficient…

    • We will add total expenses and dept data under auctions list data and detailed expenses and dept data under auction detail. We will also consider adding the previous auction ids for the lender.

      We have the goal to add all the data, that is visible on web loan/auction data, under the API’s auction detail information.

  4. As others already mentioned. There needs to be an easy way to fetch all active auctions incrementally (if-modified-since, for example). Most clients will do just that and perform all other operations (filtering,sorting,etc.) client side. This would make a lot of things possible. Sorting the auctions of a a single page does not make sense, for example.

    • Thank you for your feedback. We are adding the auction created date and time. We are also adding filter to the field, so it would be possible to get newer than auctions.

    • Yeah, create timestamp (the system’s one, you have there) would be perfect. Then it would be really easy to ask for incremental updates.

      Another way could be that i could send the newest auction id in the request and based on that you could respond with all the auctions that are newer than the one i have mentioned in request.

    • Sorry for spamming… Create timestamp wouldn’t be too cool really. “Modified timestamp” would be perfect. So when some data about the loan changes, it gets newer timestamp and so i would then re-download the data about it.

    • Well, all available timestamps would be cool to have (create,update,delete). The create timestamp to only fetch auctions having been added. The modified timestamp to only fetch auctions having been updated. Not sure about deletions of auctions. Can that ever happen? If yes, a client would need to have a way to test for a deletion as well. It’s mainly just about keeping the list of auctions in sync with the server in an efficient way. That list can get huge so the amount of data to transfer should be minimal.

    • Christian, Well, at creation, modified timestamp should be same as create timestamp, so it would not be necessary for incremental update. Also, deletion is not a real deletion, but some kind of status, so it would, again, affect the modified timestamp.

      So in the end, modified timestamp would be all that is needed for incremental update.

    • That depends on how those timestamps are maintained. I would expect the modified timestamp to be null after creation, as there has not been any modification. Only an update sets that timestamp. I am not saying that just having the modified timestamp would not work. Any API allowing a client to sync with the server without having to transfer masses of data would do, of course.

      I am thinking about a ‘SyncRequest’ with just one parameter ‘timestampLastSynced’. The response is a collection of auction identifiers only of any auction created since ‘timestampLastSynced’ and a collection of auction identifiers only of any auction updated since ‘timestampLastSynced’ and a value to provide as the ‘timestampLastSynced’ in the next request. An auction could be marked as ‘outdated’ in the UI and a user may choose to sync that single auction manually. Maybe that specific auction does not match any filter so does not need to be synced. Things like that. As a client will have to poll for changes periodically, I am heading after not needing to download lots of data every other minute. Bandwidth matters.

  5. As a client application may allow a user to choose between different kinds of strategies to place bids, I would like to request a feature allowing a user to identify the strategy used for bidding. For example, add a string parameter ‘strategyIdentifier’ to ‘Bid’ of ‘BidRequest’ and add a column ‘Strategy’ to the table ‘MY INVESTMENTS’ -> ‘INVESTMENTS’ displaying that value.

    • Looks like a user-based comment/misc. data field, which you can populate with whatever string you want… (Y)

    • Exactly. No processing involved. Just some optional information passed through and getting displayed.

    • What about allowing service providers to register their own “service keys” so that they can “sign” bid transaction with this key. (They can set name for the key or possibly use some strategy id).

      It would be useful for users to be able to distinguish even between multiple services so they can use them simultaneously. User can then examine each bid transaction and see which provider did the tx (and see provider, key name).

      Its like comment field but with authorship proof.

    • @Joonatan: Adding a comment column to the table reading “Investor,Offer amount,Accepted amount,Offer time,Offer status” of loan applications and letting a client application provide a value displayed there via the ‘Bid’ API is exactly what I am looking after.

      @n3tcarlos: In my case, I really just need a way to allow the users of the client application to comment on bids for theire personal use. The data entered is completely up to them. Nothing provable.

    • Christian, What you need is bid id, that is currently not shown. All the commenting data you can keep on your own really…

      In the end, if we would have IDs of everything we can receive from bondora, we would need nothing else from them.