Common error messages and how to fix them
When an order doesn't go through, Autoview logs an error. Most of them fall into a handful of buckets, and almost all are quick to fix once you know which bucket you're in.
The single most useful distinction is where the error came from. Some errors are Autoview-side: a credential we couldn't use, a symbol we couldn't match. Others are exchange-side: the exchange received your order and rejected it, and Autoview is just relaying their words back to you verbatim. An exchange-side error usually reads like #-1013: Filter failure with a numeric code the exchange owns. When you see one of those, the fix lives on the exchange, not in your command. This reference is grouped that way.
One note before the list. Whichever Autoview you run, the errors are the same. The webhook platform runs on our servers and accepts a POST from any alert sender. The legacy Chrome extension runs in your browser and is wired to TradingView. Same execution code, same error strings underneath.
Credential and connection errors (Autoview-side)
Invalid API credentials
Autoview has the key but can't authenticate with it. Nine times out of ten the cause is mundane: a stray blank space copied in front of or behind the key when you pasted it from the exchange. Open your exchange configuration in Autoview, find the relevant exchange, and re-check both halves of the credential for leading or trailing whitespace. The other common cause is a key created without trading permission, or with an IP whitelist that doesn't include the address Autoview sends from. Re-paste, confirm the permissions on the exchange, and confirm the whitelisted IP.
Account name not found
When you add a key, Autoview lets you give it an account name. That's for running more than one key on a single exchange. If you leave the name at the default *, you don't reference it in your command at all. If you changed it to something like AccountName, every command for that key has to address it with a=. So a default key fires fine as e=poloniex s=pinkbtc b=buy q=100% t=market, but a named one needs a=accountname in front. This error means your command pointed at an account name the key doesn't carry. Match the name, or drop it.
Timing and overload errors
#-1021: Timestamp for this request was 1000ms ahead of the server's time
This is clock skew. The extension runs on your machine, and your machine's clock has drifted out of sync with the exchange's API clock. The exchange rejects any request whose timestamp is too far off. Fix it by syncing your operating system clock to a network time source. This one is specific to the browser extension: the webhook platform runs on our servers, where the clock is already kept in sync.
Maximum retries reached: 0
The exchange returned a 503, which means their servers were overloaded and refused the order. The 0 tells you the retry count was zero, so Autoview gave up immediately. A few exchanges support an automatic 503 retry: Autoview re-sends the failed command instead of failing the whole alert. You set how many times it retries and how long it waits between attempts. Understand the risk before you turn it on. If a 503 is a false alarm and the order actually landed, a retry can place a second order, because the retry has no way to know the first one went through. Use it where a duplicate is acceptable, not where it's dangerous.
Order-size and symbol errors (exchange-side)
#-1013: Filter failure: MIN_NOTIONAL or invalid quantity
Your order size is below the exchange's minimum. MIN_NOTIONAL is an order-size filter on Binance-family exchanges, and it exists even for manual trades: the exchange won't accept dust. This is why q=100% often fails on the sell side. The exchange truncates your quantity to its allowed precision, and the leftover rounds below the minimum. Drop to something like q=95% so the truncated size still clears the floor. There's no single right number. Test the market by hand to see what it accepts, then set your quantity under that.
Unknown market symbol / instrument not supported
Autoview couldn't match the symbol in your s= parameter to anything the exchange API recognizes. The usual cause is that the alert passed the symbol from a TradingView chart, and TradingView's ticker doesn't always match what the exchange API wants. Look the instrument up in the exchange's own interface, or use the built-in syntax builder, which calls the exchange with your keys and returns the exact tickers it accepts.
OANDA traders, read this carefully. OANDA instruments use the underscore form. Write s=EUR_USD, not EURUSD and not EUR/USD. TradingView's {{ticker}} returns the concatenated EURUSD, which is exactly why the underscore form has to be set explicitly. The {{ticker}} token is TradingView's, substituted by the alert sender at fire time, not anything Autoview generates. A script or another platform builds the symbol its own way and posts the plain string.
Per-exchange gotchas
A few exchanges have their own quirks. These come from the exchange, and the fix is on their side.
OKX: order rejected on a futures position
OKX runs positions in either Net mode or Long/Short mode. If orders are rejected on OKX futures, the known fix is to set the position mode on the exchange from Net to Long/Short and resend.
Bitget: copy-trading buys and closes
Since Bitget added copy trading, opening and closing can route differently. For an open, place the buy with e=bitget-mix. For the matching close, use e=bitget-mix-copy. The e= exchange code is an extension parameter; on the webhook platform the webhook already knows its exchange.
Tradovate: symbol is inaccessible
Tradovate needs live pricing data for some symbols, and that data sits behind a market data subscription. You can often avoid needing it. Open new orders with t=market, close positions with c=position ps=position, or pass exact values using the fixed parameters fp, ftp, fsl. If you do have the price, supply it with price=.
Tradovate: account name not found
Tradovate reports the order targeted an account name it doesn't have, listing the accounts it does have. Check that the account name in your command matches a real Tradovate account exactly, live versus demo included. If you log in fresh from a new machine, such as a zone, Tradovate may also require you to approve the device by email before trades execute.
When the error isn't here
If the message in your log carries a numeric code from the exchange (#-2015, #-2019, -40762, and so on), it's the exchange rejecting the order, and Autoview is relaying it word for word. Search that exact code in the exchange's API documentation. It will tell you precisely what it didn't like, whether that's permissions, insufficient margin, or a parameter the exchange wants formatted differently.
For anything Autoview-side, the fastest diagnostic is a dry run. Add d=1 to the command. Autoview parses it, shows you exactly what it would have sent, and posts nothing to the exchange. That tells you in one shot whether the problem is your syntax or the exchange's response.