Welcome to our new support center! Some articles may still be missing; they will be added shortly. For the old support documentation go to https://support.altrady.com. If you have questions, open a new ticket here. New tickets on support.altrady.com won’t be answered; existing tickets will be finalised there.

Altrady Support Altrady Support

Problemen oplossen: TradingView webhook-signalen triggeren geen orders in Altrady

Als een TradingView-alert afgaat maar er geen order in Altrady verschijnt, ligt de oorzaak bijna altijd bij een van deze twee dingen: het signaal is prima aangekomen maar werd geblokkeerd door een bot-filter, of de JSON-payload bevat een kleine fout. Beide zijn snel te vinden zodra je weet waar je moet kijken, en dit artikel leidt je er stap voor stap doorheen.

Deze handleiding behandelt de signaalkant: JSON-payloads, TradingView-alertinstellingen, API keys, symbolen en filters. Ligt het probleem juist bij de bot (de bot staat uit, de exchange API key is stuk, of er is onvoldoende saldo), gebruik dan Signal Bot Not Trading? A Troubleshooting Checklist.

Controleer eerst deze zes dingen

  1. Open het error log van de bot en zoek naar een melding “Filters did not match”.
  2. Valideer je JSON in Swagger.
  3. Controleer of de api_key en api_secret in de payload bij de juiste bot horen.
  4. Controleer of het symbol bestaat en verhandelbaar is op die exchange.
  5. Controleer of side in elk signaal staat, ook bij close-signalen.
  6. Controleer de ordergrootte en het accountsaldo.

De meeste “genegeerde” signalen zijn eigenlijk wel door Altrady ontvangen, maar geblokkeerd door een filter of fout, niet onderweg kwijtgeraakt. Dat is goed nieuws: het betekent dat de oplossing meestal een instellings- of payload-wijziging is, geen verbindingsprobleem.

Begin bij het error log van de bot

Het error log van de bot registreert elk signaal dat is afgewezen door een filter-mismatch, en waarom, dus beantwoordt dit de meeste gevallen op zichzelf. Een veelvoorkomende melding is:

“Filters did not match: Max per market”: de bot heeft al een open positie op die markt, dus slaat hij het nieuwe open-signaal over in plaats van er een tweede positie bovenop te stapelen. Stuurt jouw strategie vaak signalen, dan kan het lijken alsof er maar een deel “aankomt”; in werkelijkheid staat elk overgeslagen signaal met deze melding in het log.

Moet jouw strategie een bestaande positie uitbreiden in plaats van een nieuwe openen, stuur dan een signaal met action: increase in plaats van open. Zie de Webhook Signal Reference voor het payload-format.

Andere entry-filters, zoals een limiet op het aantal gelijktijdige posities, blokkeren signalen op dezelfde manier. Wat de reden ook is, het log toont het,

Swagger UI met het uitgeklapte webhook-signaalendpoint, met een voorbeeld-JSON-payload ingevuld in het Try it out-verzoekveld, klaar om te Executen.🔍 Click the image to see a larger version dus controleer dit altijd voordat je iets anders aanpast.

Test je JSON in Swagger

Voordat je een payload in een TradingView-alert verwerkt, test je hem rechtstreeks tegen de API van Altrady: open het signal bot positions endpoint in Swagger, plak je JSON in het testformulier, en verstuur het. Dit is de snelste manier om te bevestigen dat de JSON zelf geldig is en geaccepteerd zou worden, zonder te wachten op een live alert.

Wees je ervan bewust dat het testformulier echte verzoeken doet: met een geldige api_key en api_secret plaatst een geldige open-payload een echte order tenzij je de test-vlag toevoegt:

"test": true

Verwijder die vlag voordat je live gaat. Een payload waarbij de test-vlag nog aanwezig is, kan verwerkt worden als een nulwaarde- of paper-only resultaat in plaats van een echte order te plaatsen.

Heb je TradingView-variabelen in je JSON, dan worden deze niet herkend door Swagger; Swagger heeft geen toegang tot TV, noch tot je indicator of strategie. Ze moeten vervangen worden door geldige waarden.

Foutmeldingen en wat ze betekenen

De webhook (en het Swagger-testformulier) beantwoordt een afgewezen verzoek met een specifieke fout, en de HTTP-statuscode geeft snel uitsluitsel: een 400 betekent meestal dat de JSON zelf niet goed gevormd is (een syntaxfout), terwijl een 422 betekent dat de JSON geldig is maar een waarde erin fout is. De specifieke melding wijst precies aan welke. Hier is elke melding en de oplossing:

Credentials en bot-status

  • “Signal bot not found”: de api_key komt niet overeen met een bot. Kopieer de payload opnieuw vanuit de Webhook Builder van de bot.
  • “Invalid secret”: de api_key klopt, maar de api_secret niet. Kopieer beide vanuit dezelfde Webhook Builder van de bot.
  • “Signal bot is not a webhook bot”: de credentials horen bij een bot waarvan de signaalbron geen Webhook is. Maak een webhook-bot aan of schakel over naar de keys van de juiste bot.
  • “Signal bot stopped”: de bot staat uit. Een gestopte bot accepteert alleen start_bot, start_and_open, increase, reduce en close; start de bot (in de app of met een start_bot-signaal) voordat je open-signalen stuurt.

Markt en symbool

  • “Exchange missing” of “Exchange used in tv_exchange does not exist”: de waarde van exchange of tv_exchange werd niet herkend. Het foutantwoord bevat de geaccepteerde waarden, dus kies de jouwe uit die lijst.
  • “Market not found using symbol: …, or tv_ticker: …”: het pair bestaat niet op die exchange, of het symbol-format klopt niet. Gebruik het eigen symbool van de exchange of Altrady’s EXCHANGE_QUOTE_BASE-vorm, bijvoorbeeld BINA_USDT_BTC.

Order- en positielimieten

  • “Order Type X is not supported for this exchange”: de exchange biedt dat ordertype hier niet aan; wissel tussen limit en market.
  • “Market order doesn’t support quote currency” of ”… base currency”: bij een market order accepteert die exchange maar een van de twee groottevelden, en jij gebruikte de andere (sommige exchanges accepteren beide, sommige alleen base, sommige alleen quote). Wissel naar het andere sizing-veld: base_amount in plaats van quote_amount, of andersom. Wil je vooraf zien wat een gegeven exchange toestaat, open dan die markt in de Trading widget: de getoonde groottevelden voor market orders (base en/of quote) zijn de toegestane opties. Zie Een market order plaatsen.
  • “Too many positions opened”: de bot zit al op zijn maximum aantal gelijktijdige posities. Sluit een positie of verhoog de limiet van de bot.
  • “Too many open orders, cannot add more LIMIT orders”: een increase- of reduce-signaal zou de open-orderlimiet op die positie overschrijden. Wacht tot orders vullen of annuleer er een paar.
  • “Reverse is only supported on futures exchanges”: action: reverse werkt niet op spot-markten; stuur in plaats daarvan een close gevolgd door een open.

De eigen marktfilters van de bot (gemeld als validatiefouten zoals “Does not match quote currency”, “Does not match the minimum volume”, “Does not match the maximum volume”, “Does not match the minimum price”, “Does not match the maximum price”, of “Does not match exchange”): de markt of prijs van het signaal valt buiten wat jij in de instellingen van de bot hebt ingesteld. Pas de quote-valuta-, volume- of prijsfilters van de bot aan, of stuur het signaal naar een bot die voor die markt is ingesteld.

Een slecht gevormde payload (ontbrekende side, zowel symbol als tv_ticker tegelijk, ongeldige JSON door een niet-aangehaalde TradingView-placeholder) wordt afgewezen met een veld-specifieke validatiemelding voordat een van de bovenstaande wordt bereikt. Het Swagger-testformulier toont dit direct.

In het error log van de bot beginnen alle filterafwijzingen met “Filters did not match”, gevolgd door de reden:

  • Max per market: de bot heeft al een open positie op die markt.
  • Max per market single mode: een One-Way futures-markt houdt al een positie aan, dus kan er geen tweede in beide richtingen openen.
  • Max per market hedge: een hedge-mode futures-markt houdt al een positie aan op diezelfde kant.
  • White list / Black list: de markt is uitgesloten door de whitelist of blacklist van de bot. Zie Signal Bot Whitelists, Blacklists and Market Filters Explained.

Foutlogpaneel van een bot in Altrady met een afgewezen signaal in de vorm van een ‘Filters did not match: Max per market’-achtige melding.🔍 Click the image to see a larger version ## Controleer de keys en het symbool

Elke signal bot heeft zijn eigen api_key- en api_secret-paar. Een close- of sell-alert moet de credentials gebruiken van dezelfde bot die de positie heeft geopend. Verstuur je deze met de keys van een andere bot, dan sluit dit de positie van de eerste bot niet, zelfs als symbool en side overeenkomen.

Werkt dezelfde JSON voor de ene ticker maar niet voor de andere, dan ligt dat meestal aan de waarde van symbol: die is verkeerd geformatteerd, of die markt is niet beschikbaar op de exchange die je aanspreekt. Bewaar de exacte JSON van de mislukte alert; support zal hierom vragen om het symboolprobleem te achterhalen.

Close-signalen die genegeerd worden

Als een close-signaal genegeerd lijkt te worden:

  1. Controleer of side in de payload overeenkomt met de kant van de open positie; hierop matcht Altrady het signaal met de positie.
  2. Controleer of de api_key/api_secret bij de bot horen die de positie daadwerkelijk aanhoudt (zie hierboven).
  3. Test de exacte close-payload in Swagger om een JSON-fout uit te sluiten voordat je uitgaat van een platformprobleem.

Wat het webhook-antwoord wel en niet vertelt

Het HTTP-antwoord dat naar TradingView terugkomt, bevestigt alleen dat het verzoek is ontvangen. Het legt niet uit waarom een positie later niet werd geopend (bijvoorbeeld door een max-per-market-filter dat het blokkeerde). Synchrone problemen komen terug als de foutmeldingen hierboven; asynchrone afwijzingen verschijnen alleen in het error log van de bot binnen Altrady, dus controleer het log in plaats van alleen op het webhook-antwoord te vertrouwen.

Kom je er niet uit?

Heb je de filters gecontroleerd, de JSON gevalideerd in Swagger, en de keys en het symbool bevestigd, neem dan contact op via de support chat met:

  • Het label van de bot
  • De exacte JSON-payload van de alert
  • Het tijdstip waarop de alert afging

Met deze drie gegevens kan het team precies traceren wat er met jouw signaal is gebeurd en het van daaruit oppakken.

Was dit artikel nuttig?