The first step in attempting to use an API in Thunkable should always be to make sure it works in a browser as https, in Postman, or as a curl command. Once that’s working, then move to Thunkable blocks. It’s harder to get the blocks correct than it is to do any of those other methods which is why people usually start with those.
Do you have a curl command that you could try? If not, can you ask the developers to provide you with a sample curl command? That’s often very helpful because it shows the proper header/query/body pairs.
Are you able to share a link to the API documentation? I couldn’t find it.
Yeh, I’m completely new to APIs and I struggled to create a working URL I could just test. The documentation is erm, sparse: Whisper API
There’s is a cURL section on there, I just don’t know how to use it is all
I tried it in Postman as recommended and included the Content-Type in the Header as recommended in the other section, then moved the queryparams into the body - e voila!
now I just need to get it to work in Thunkable, but I at least know the API works!
That’s a huge first step! Also, nice choice of text!
Postman can generate curl commands. It would be helpful if you can post the curl command here (make sure to hide the API key). If you click the code button (</>) in Postman, you can see the curl for the API call you ran:
I don’t see anything obvious that would cause that error. You might forward the curl command to the developers to see if they can suggest anything, along with the error message you’re getting. I haven’t seen a “x-www-form-urlencoded” header before. There’s a chance you might need that header in Thunkable but I don’t think so. As a test, it might be worthwhile to include that as the Content-Type value.
i think your headers in the web api config area are coded wrong. you can either correct them there or remove them from config but use these blocks instead:
if you prefer to keep them in config, then use property “Authorization” with value “Bearer xxxxapikeyxxxxxx” and property “Content-type” and value “application/x-www-form-urlencoded”
if it still doesn’t work you might try deleting the block marked X below:
and if it still doesn’t work, change the numSpeakers value from “2” to 2 (ie.text to number).
OK - so I was pretty sure Authorization through config was working because when I get this wrong I get the error {“detail”:“Not authenticated”}. But, I was worried the Content-Type was playing a part. If I just added a ‘Set WhisperAPI Header to’ for Content-Type it seems to nullify the config API-key setting. So, I tried your way and set them both via the blocks. Sadly, that still gives me an authentication error. Here’s what I ran:
Note - I added an additional button to just run a pre-created url instead of spamming Cloudinary with new files all the time.
I also tried removing the block to add the data sub-property but that gives me the normal ‘url not set’ error.
Finally, I also tried the 2 > “2” (good shout) but again, no dice.
One thing which seems really obvious but might not be from the way I’m describing everything: The cURL from the POSTMAN which worked is completely different in terms of format from the thing I’m sending it. As in, the cURL features data encodes like this > --data-urlencode ‘diarization=false’
The JSON I’m sending it is in key:variable pairs like {“diarization”:“false”}. Is it this?
Here the URL is set to a copy and paste of the working cURL from POSTMAN. I removed the authorization etc. from config first so all of that is going into the cURL POST call. I get an Network Request Failed error. ArGH!
I cut all the variables I could from the call in POSTMAN and tested it so it still worked. Here’s the stripped down version I used above:
Removing convert to JSON from object block for the Header stopped me getting the Auth error. So, I thought maybe if I also do that for the body that might work… I get something new:
422{“detail”:[{“loc”:[“body”,“url”].“msg”:“str type expected”,“type”:“type_error.str”}]}
So, why does it think my url is not formatted as a string?
But, if I do something daft e.g. leave the url as ‘url=res.cloudinary.com…etc’ then it recognises that the url isn’t correct and I get:
'200{“error”:“There was an error uploading the file. Check to make sure your file or file url is valid. Also, make sure that you uploaded a valid file type, language, and task.Note: if you set diarization to true, fewer files types will be accepted!”}
ofc - I haven’t set any of those additional parameters so they should all be default and working OK. It certainly worked when I ran it in POSTMAN.
You may want to remove the Authorization string from your post.
I know you’re grabbing at straws and I’ve been there, believe me. But @manyone and I have a lot of experience with Thunkable and APIs and I would recommend that you keep the Body section in this format:
If you’re getting an authorization error then the server is recognizing your API call but not allowing it. So you need to fix the authorization rather than changing the Body or switching to Query Parameters. You’re adding a lot of variables (scientific variables) to the problem by switching so many things around. And again, I’ve been there but it makes it hard for anyone to follow and suggest something because when one thing doesn’t work, you’ve changed two or three other things after that.
I think the screenshot you have here is very promising:
So I would work on the authorization to figure out why your “Bearer _____” string isn’t accepted by the API server. And I know it’s accepted when you run the Curl command (I just ran it once) but for some reason it’s not working in Thunkable. Double-check the string carefully, making sure you have "Bearer " (with a space after it) before the key value.
Edit: Then again, ChatGPT says otherwise:
No, you don’t need to convert the object to JSON in Thunkable. The “Web API” block automatically sends the data in the “Body” section as form-data, which is the required format for this API call based on the curl example provided.
When I’m working with APIs, I prefer to leave everything in the API component properties panel blank and just use blocks to configure the API call. The downside of this method is that if you share your project, your API key is included. But I typically don’t share projects with API calls with anyone. I’m just wondering if maybe your authorization string is included in the properties panel and is causing a conflict.
Edit: Can you try one other thing? Add quotes around the url string:
note that body is coded for 4 key values: id, auth_key , channel, and turn). you can code your parameters the same way: note that parameters after the,1st start with “&” - to signify continuation - ie. (key1=val1&key2=val2&key3=val3…)
OK - sorry for being confusing. I’m trying to test and try everything I can think of rather than get spoon fed but I get that that can be confusing from the outside.
So if I test your idea first @tatiang. I’ve removed all the info from the config for the API. Everything is being done in blocks. I’ve also double checked the space between Bearer and the API key. I’ve also added the extra “”'s around the url as described.
Note - I’ve reset the API key after I blundered and exposed it - which is why you might have had trouble on that second test
This is what I’m left with:
I get a: 200{“error”:“There was an error uploading the file. Check to make sure your file or file url is valid. Also, make sure that you uploaded a valid file type, language, and task.Note: if you set diarization to true, fewer files types will be accepted!”}
Removing the additional “”'s gives me the:
422{“detail”:[{“loc”:[“body”,“url”].“msg”:“str type expected”,“type”:“type_error.str”}]}
Also, for those that follow I was also thinking about trying to bury the API Key back into the configuration as @tatiang had mentioned the security issue with sharing and having the key exposed. So, once I transferred the code back into the main button I also cut the blocks for setting the Headers (Authorization and Content-Type) and added them back into the config panel. two things: 1) you must have both headers included for it to work 2) it works!
Ive been looking back at this thread recently as im trying to get whisper work as you were here. Would you be able to help me understand what goes in the blocks? I have the transcribe url in web api, then in the body im putting Bearer: (my api key), but i dont understand why you application/x… for the content type. Is thay just what you always have to put in there, or specific for you?
Also, on the ID, auth, channels, turn in the solution you marked, what details were going in there??
Sorry if these questions sound stupid. Im a bit of a neewb so just finding my way.
