If a Tigzig API Keeps Returning the Same Error, Read the Response Body. There Is Almost Always a Hint in It.
Published: August 25, 2026
If you are calling a Tigzig API and keep getting the same error back, read the response body. Now you will almost always find a hint sitting in it that tells you what went wrong. That is one of the features I have enhanced hugely this week.
I parse what hits the API, try and work out what broke, and put the answer in the message. Usually it names the exact character, or the exact table. It's not perfect and not every error will carry a hint but most do and usually they are right.
This is live across the Tigzig Data Surface, the Cricket DB-MCP, the Mutual Fund and Yahoo Finance APIs and others.
For the APIs supporting GET, the commonest problem by far is not your SQL. It is the URL mangling your SQL before it reaches me. A plus sign arrives as a space, line breaks vanish, and you end up looking at correct SQL being told it is invalid. The message will say exactly that.
So before the next retry, print the body and see what it says.
API Hub: tigzig.com/apis
Whether you see the hint at all depends on the tool
curl shows it to you already. Plain curl with no flags prints the response body, error or not.
The one exception is -f, or --fail, which a lot of scripts use. With -f curl prints nothing at all, so skip that. Also, bare curl exits 0 on a 400, so a script chaining on && will carry on as though the call worked.
Python hides it, and the two common libraries hide it differently.
urllib raises on a 400 by itself, and the exception reads "HTTP Error 400: Bad Request" with nothing else in it. The hint is in the response, and you only get it if you ask:
try:
r = urllib.request.urlopen(url)
except urllib.error.HTTPError as e:
print(e.read().decode())
requests does not raise at all unless you tell it to, so a 400 comes back looking like an ordinary result and the code carries on. If you call raise_for_status() you get "400 Client Error: Bad Request for url: ...", which names the URL and still leaves the hint out. It is sitting in r.text.
JavaScript hides it a different way. fetch does not throw on a 400 at all, so a try/catch around it catches nothing and the code carries on as if the call worked. You have to check r.ok and then read r.text().
Some of what the hint will tell you
If a character got mangled on the way in, it names the character and shows you the SQL as it arrived, so you can see the difference between what you sent and what I received. That one catches most people.
If you ask for a table that is not there, it lists the real table names, the columns, and the key they join on. So the next call works rather than being a second guess.
If the query is too big or asks for too much back, it says which limit you hit and what the number is.
None of this needs an account or a key. It is the same open API either way, and the error path gets the same attention as the success path.