Is Paid API Usage Allowed

For the Appathon, I am looking for APIs and they are all paid. I saw that the extensions used in an app have to be free, but do the APIs used have to be free too?

I believe everything that is paid is not allowed, because everyone should have fair access to it.

5 Likes

All paid ? :cry:

Frequently some 'paid' api's have some 'free' usage. The api provider may require registration but have free limited use.

What information does the api you want to use provide? There may be alternatives. :slight_smile: and if we know what type of api someone might provide a suggestion to get around the issue doing something differently.

How will the judges test the app ?

They'll use the API key/account that I have, but if paid isn't allowed then it's a moot point.

Calling/texting. There are free versions but they are very limited, so if anyone has any suggestions that would be much appreciated. I'm using APIs rather than the phone itself because direct calling has been disabled, and it works better for the app itself.

Does this mean your phone doesn't have a service contract and you have to use WIFI
or the Phone/sms components no longer have a dial direct option and you have a service contract. Social describes a way to enable direct calling. You may also send text messages without user interaction by calling SendMessageDirect instead, but this adds dangerous permissions to your final app. In this case you could use the Companion version with a u in it. (instead of Companion 2.63 use 2.63u ).

A possible alternative if you do not have WIFI is to use Google Voice. This feature might still be available. https://community-appinventor-mit-edu.ezproxy.canberra.edu.au/t/google-voice-issues-regarding-sms/148 says it is limited.

Good luck with an alternative.

So when judging, will the judges also use the 2.63u version?

The link doesn't exist.

I get the same error described in this post:
https://groups.google.com/g/mitappinventortest/c/BxNANsmgLEY/m/kcN6O4v6DgAJ

But basically, I'm trying to use third-party telecom APIs because the user has even less interaction with the backend, allowing them to say something and not have anything trigger on their phone which is key for my app.

Yes, the send direct don't work.

Probably but you may need to advise them. Perhaps @Peter will know and comment.

It does link for me. Try this Texting instead.

So, use Companion 2.63u and use the SendMessageDirect Block that will be exposed as indicated in the above Texting link.

??? Sorry, I have no idea what you mean.

Alright, thank you, will do. Do you have the link for the download of the u version?

I just mean that by using another API, the user doesn't have to manually do anything like disconnect the call or even talk as the APIs provide Text to Speech software.

You can use inbuilt text to speech component for that! Will it work for you?

uCompanion

QrCode downloads Companion 2.62u to your cell phone.

This might help The attached simplified SMS_Texting .aia (5.0 KB) SMS app (no LocationSensor etc) responds to Text messages in the app on an Android 4.2 cell when the apk is installed.

I still get the same IOError I linked before. But if I were to employ the paid API, would it result in a disqualification?

Looking at the rules I don't see a specific rule against using paid APIs just paid extensions. But....... looking at the spirit of the Appathon you should only use resources that are available to everyone and not just to users that can spare the money.

The only one that can answer this would be @Selim_Tezel or @ewpatton. Since the submissions are due on July 30 at 23:59 AOE (UTC-12) I wouldn't take a change with that and use a free API. Judges will use the latest companion with the http://code.appinventor.mit.edu.ezproxy.canberra.edu.au/ server to judge your project.

2 Likes

Could I ask the user to generate their own API key? And if they choose to purchase anything, would that still follow the Appathon guidelines?

Still the same response. If you expect that users have to purchase something to use your app it is not in the spirit of the Appathon. It has to be usable for everyone, with or without money.

2 Likes

We have decided that paid APIs are not appropriate in Appathon submissions because it is not fair to other participants who may not be in a position to pay for API access.

8 Likes