Bondora zieht den API-Stecker

Oktaeder · P2P Legende Anmeldedatum: 13.07.2010 Beiträge: 10739 Wohnort: Bei Karlsruhe

Es wurde ja schon mal angesprochen: etwas zu programmieren und debuggen ist quasi unmöglich geworden. So ist zB pageSize ein Pflichtfeld bei Abfragen geworden. OK, eingefügt. Bis zum nächsten Versuch: 1h warten.
In drei Monaten werden wir lesen, dass die API abgeschaltet wird, weil sie keiner mehr nutzt. Ja, war alles schon mal da. So hat man auch das manuelle Bieten auf dem Erstmarkt getötet. Nehmt unser Autoinvest oder besser noch g&g, oder sucht euch einen anderen Anbieter.
_________________
Mein Blog rund um p2p Kredite
Bondora/XIRR ca. 12%/ Investiere per API.
Stand 9/2023

Weitere Anlagen bei Swaper*,peerberry,afranga,lendermarket und estateguru

Zedandi · Anmeldedatum: 02.11.2016 Beiträge: 1486

Realarms · Anmeldedatum: 22.03.2017 Beiträge: 246

Realarms · Anmeldedatum: 22.03.2017 Beiträge: 246

Realarms · Anmeldedatum: 22.03.2017 Beiträge: 246

Sie scheinen noch nicht mal den Cooldown timer richtig implementieren zu können:

GET https://api.bondora.com//api/v1/secondarymarket?PageSize=1000&ShowMyItems=False response <Response>
https get returned at 2019-06-02 09:16:17.335546, taking 0:00:00.146095
response json: {u'Errors': [{u'Message': u'API calls quota exceeded! maximum admitted 1 per Hour.', u'Code': 429, u'Details': u'Retry after 3239'}], u'Success': False}

(3246 Sekunden später - als mehr als die angegebenen 3239 Sekunden):

GET https://api.bondora.com//api/v1/secondarymarket?PageSize=1000&ShowMyItems=False response <Response>
https get returned at 2019-06-02 10:10:23.070811, taking 0:00:06.638190
response json: {u'Errors': [{u'Message': u'API calls quota exceeded! maximum admitted 1 per Second.', u'Code': 429, u'Details': u'Retry after 1'}], u'Success': False}
excessive GET errors 2/2 - <Response>

WTF...

Zedandi · Anmeldedatum: 02.11.2016 Beiträge: 1486

Realarms · Anmeldedatum: 22.03.2017 Beiträge: 246

Praetorian · Anmeldedatum: 13.09.2007 Beiträge: 96

Ich denke Bondora* hat sich zu dem API-Schritt gezwungen gesehen, weil wir offensichtlich einige API-User hatten, die aufgrund mangelnder Programmierkenntnisse die API einfach zugespammed haben. Finde ich durchaus verständlich seitens Bondora.

Und ich muss auch sagen, dass sich Bondora* bzgl. konkreter Verbesserungsvorschläge immer offen und interessiert gezeigt hat (CancelOnRepayment und Reschedule waren z.B. Ideen von mir, welche sehr zügig umgesetzt wurden.

Deshalb die Bitte an die API-User: Lasst uns doch einfach gemeinsam eine Anforderungsliste erstellen, mit der wir arbeiten können und welche nicht deren Server zumüllt.

Ich bräuchte folgendes:
Kurzen Cooldown (z.B. 5 Minuten) auf /investments
Zuverlässige WebHooks für Primär- und Sekundärmarkt
Kurzen Cooldown auf /balance (z.B. 5 Minuten)
Test-Schnittstelle für Dummy-Anfragen?

/secondarymarket ist mir persönlich egal, wenn die WebHooks funktionieren. Ich denke hier kann man aber sicherlich auch verhandeln. Was wäre ein sinnvoller Wert? Alle 10 Minuten?

Realarms · Anmeldedatum: 22.03.2017 Beiträge: 246

WENN die webhooks so funktionieren würden, wie vermarktet, würde das alleine ca. 99,9% meine API requests abdecken.

Problem dabei (und nur der Teil, der kritisch ist):

a) webhooks haben 5 bis 60 sec verzögerung gehabt ggü /secondarymarket bzw /auction. -> wertlos
b) webhooks sind inkonsistent (bis zu 10 sec differenz zw. zwei usern, und welche notifications welcher user bekommt, stimmt nicht immer überein (etwa 95-98% sind wohl ident, aber zu leicht unterschiedlichen zeiten
c) automatisches unblocking / retry von webhooks geht nicht - ah, zumindest wurde in dem punkt die API dokumentation überarbeitet (das automatisches unblocking nicht mit dem löschen des fehlercounters gemacht wird)
d) keep-alive sessions mit webhooks führen zu falschen fehlern (die nicht gecleared werden)
e) nach (manueller) reaktivierung dauert es bis zu 15 min, bis die webhooks aktiv sind
f) webhooks sind offensichtlich ein nachträglich dazugepapptes feature (windows server, statt linux wie normale API, zeitverzögerung, unterschiedliches verhalten der lower layers,...)
g) webhooks sollten die komplette historie der Loans mitliefern (api/v1/loanpart/{id})
h) alle dokumentierten webhooks sollten auch wie dokumentiert implementiert sein, und FUNKTIONIEREN. Ich habe in meinen Test von diesen Typen hier:

Auction_Published *
Auction_Funded
Auction_Rejected
Auction_Accepted
SecondMarket_Published *
SecondMarket_Updated
SecondMarket_Bought
SecondMarket_Canceled
SecondMarket_Sold

nur die beiden mit * markierten gesehen.

Bei den anderen auctions kann man argumentieren, dass einen da die WHs nur interessieren, wenn man selbst (einmal pro Stunde? SRYL?) geboten hat. Aber bei secondmarket_updated wäre jede Änderung an einem bereits laufenden interessant (wenn zB ein roter Kredit wieder anfängt zu zahlen, also zB eine Rückzahlung erfolgt ist)...

Solange du mit webhooks nicht kompetitiv mit den internen Portfolio und PortfolioPro mithalten kannst, helfen dir die nix - die Auktionen sind ja nur mehr 10 sec oder so offen - und via webhooks kann schon ein großteil der zeit vergangen sein (wo die internen, richtig in die SQL infrastuktur eingebundenen PMs gelaufen sind), bevor du überhaupt was davon mitbekommst...

IMHO wäre webhooks richtig zu implementieren ein deutlich größerer Aufwand.

Und nur um die Last zu senken, würde eine erhöhung des Cooldowns von 1 sec auf 2 sec bereits 50% geholfen haben....

Mit einem moderaten Cooldown auf 5 sec - innerhalb der Auction Fristen - wäre die Last um etwa 80% gesunken - wozu muß die Last auf ~0,3 promille sinken - soll da ein Raspberry Pie I ausreichen?

Oder ist Bondora* draufgekommen, das AWS/CoLo doch nicht so günstig ist, wenn man konstant hohe Last hat (da sind lokale Resourcen schnell kostengünstiger...)

Bei den aktuellen Limits habe ich den starken Verdacht, das die internen DB Caches nun oft leer sind, und nicht innerhalb der Web API timeouts die resultate liefern, worauf die API nun 429 und dann 400 liefert (oder 429 1h, und dann 429 1sec)...

Da man die vorgeschobene Behauptung von zu hoher Last mit deutlich weniger drakonischen (und fehlerträchtigen) Methoden hätte erreichen können, glaube ich nicht, das dies das Ziel war.

Wohl eher, die API User jetzt endlich rauszuwerfen (ohne die Funktionalität nominell aufzugeben), und möglichst alle Investoren auf G&G einzuschwören...

Zedandi · Anmeldedatum: 02.11.2016 Beiträge: 1486

Oktaeder · P2P Legende Anmeldedatum: 13.07.2010 Beiträge: 10739 Wohnort: Bei Karlsruhe

Was glaubst du, wieviele konstruktive Mails mit genaueren Erläuterungen ich geschickt habe... die Antwort war enttäuschend, falls überhaupt eine kam.

Ich kann mir zB nicht Erklären warum man Balance so runterbremsen muss.

Insgesamt verlangt Bondora*, so wie sie es dokumentieren, eine komplette parallele Buchführung. Das ist absurd.

Investment ist für mich ok so. 5 Request auf 2nd Market alle 15 Min wäre super.

BTW ist das Laden noch langsamer geworden. Ich hätte nicht gedacht dass das überhaupt möglich ist :-/
_________________
Mein Blog rund um p2p Kredite
Bondora/XIRR ca. 12%/ Investiere per API.
Stand 9/2023

Weitere Anlagen bei Swaper*,peerberry,afranga,lendermarket und estateguru

Praetorian · Anmeldedatum: 13.09.2007 Beiträge: 96

@Realalarms: Ich finde die keep alive Funktionalität ist nicht kriegsentscheidend. Wenn die Verbindung jedes Mal neu aufgebaut wird, dann ist es halt so. Deine Aussagen zur Latenz kann ich nur bedingt nachvollziehen. Ja, beim /secondarymarket war es schon lange so, dass manchmal schnell ne Antwort kam, manchmal es aber länger gedauert hat. Im übrigen waren die Abfragen gut, die länger gedauert haben, weil dann tatsächlich neue Einträge aus der Datenbank hochgekommen sind. Die Caches waren jedesmal bereits von anderen Leuten geplündert. Klar könnte man hier Arbeit reinstecken und ein Realtime fähiges System bauen, das halte ich aber für ein Unternehmen von der Größe wie Bondora* für Overkill.

Ich fasse mal soweit zusammen:
Kurzen Cooldown (z.B. 5 Minuten) auf /investments
Zuverlässige WebHooks für Primär- und Sekundärmarkt
Kurzen Cooldown auf /balance (z.B. 5 Minuten)
Test-Schnittstelle für Dummy-Anfragen?
Kurzen Cooldown auf /secondarymarket (5 Anfragen alle 15 Minuten).
Alternative: Alle Cooldowns auf 15 Minuten + 5 Anfragen

Ich sammle mal die Punkte hier noch ein paar Tage und gebe das dann an Bondora* weiter.

@Oktaeder: Ich glaube gerne, dass Du viele konstruktive Mails geschrieben hast. Ich denke aber, dass es für Bondora* einfacher ist, wenn wir gemeinsam eine Position mitteilen und die nicht mit jedem einzeln hin und her schreiben müssen. Wir sollten hier so ne Art PowerUser Group etablieren, wo wir gemeinsame Punkte bündeln. Bondora* weiß genau, dass die API-User die leidenschaftlichsten User sind und ist sich des Mehrwertes dieser Gruppe durchaus bewusst. Allerdings bewegen wir in Summe auch nicht das komplette Portfolio.

Praetorian · Anmeldedatum: 13.09.2007 Beiträge: 96

Ich habe obige Ideen nun an Bondora* kommuniziert. Sie sitzen nächste Woche in einer größeren Runde zusammen und werden die einzelnen Punkte und das weitere Vorgehen diskutieren.

Da kommt bestimmt etwas dabei heraus. Danke für Euer Feedback!

Realarms · Anmeldedatum: 22.03.2017 Beiträge: 246

Realarms · Anmeldedatum: 22.03.2017 Beiträge: 246

Webhooks: 0
altes Script nun 1x Stunde aktiv: 13 (~2 pro Tag)

Der ehrlichkeithalber, die Webhooks haben rund 3x häufiger angeschlagen auf SecondaryMarket - aber kein einziges Mal konnte das Skript danach gleich einen Kauf erfolgreich durchführen (Item not on sale) - soviel zur "verbesserten" Geschwindigkeit der Webhooks - immerhin kann es aufgrund der cooldowns nicht mehr verifizieren was da sonst so im Hintergrund passiert...

Jeweils gefiltert auf extremen Discount gefiltert ...