Api key / Usage Limits

Api key / Usage Limits

UpstairsericsUpstairserics Posts: 10Member

I really don’t understand the introduction and application of the api key. Can you pls help with a couple of queries please?

(1) the whole process is quite ‘long tail’, ie it takes a finite time to complete and while it’s in process you cannot (rightly so) trigger another audio notification. The api uses a result code 409 to indicate this contention state and handling against this code is a useful way of slugging the users app to retry until the speaker is free to handle the next notification. The trouble I see is that any call to the api to check for 409 counts as one call against the 100 limit even though a notification was not executed. Is this the case?

(2) what is the thinking behind the inconsistency of application between the control api and the audio notification api? One uses it, the other doesn’t.

(3) my speaker is in my network and a call to the api does not hit or impact your cloud app? The speaker itself does not seem to be impacted by frequent calls, not a blink. In which case what are you trying to protect or monetise?

(4) how would you count one functional request made to 3 speakers? The way I see it you cannot call a group so it comes out on all speakers. So we have a 3 times hit on the 100 limit even though I am spreading whatever risk you are trying to mitigate across 3 devices. This seems draconian and will only further put off the home automators.

I had great expectations for this, and indeed developed some interesting trials with audio now playing announcements, environment sensor read outs etc but starting to think Soundtouch may not be the way forward given the constraints.

Comments

  • edited 01/09/2018 - 06:06
    johnlijohnli Posts: 4Member

    Agree.

    If there's no cloud API or process involved, there should not have an API key.

    The Notification API design seems a bit confusing for developer, I think it's purpose is just like iOS Push Notification, it wants give developer the ability to send Notification, but meanwhile it limits it to several or dozens of Notification per day don't want too much disturb for user. But even the iOS Push Notification don't have that limit, user always have a choice to disable the Notification or uninstall the App which send too much Notification.

    So it seems the only reason to have API key and call limit is because some cloud resource involved, but from the API call (you still need to find the local Speaker IP) and the Notification function, there should not have any cloud resource involved, and also this should not go to cloud from privacy perspective. A WIFI speaker is still a speaker, it should work standalone without any internet connection.

  • Zach@Bose[email protected] Posts: 156Admin

    Hi Upstairserics and johnli,

    First, sorry for the delay in reply -- I was out last week and have been slow in catching up.

    Overall, in response to the core of your questions: as I mentioned in this other thread, we see the Audio Notification API as a uniquely powerful one (compared to the control API), and we want to work with developers to make sure that power is being used for good when deployed to many customers. The API key approach lets us release this API here for anyone to use in development or home environments, while simultaneously limiting broader use until after we've worked through a certification process. This certainly has it's trade-offs, but it's the balance we've struck for now.

    With that said, addressing a few of the specific concerns:

    • 400, 403, and 409 errors all process/return before we check the API key, and therefore any calls returning these do NOT count against the quota
    • 3 successful individual requests to 3 speakers will indeed count as 3 calls against the quota
    • The use of the API key has no ties to API monetization. For transparency: we believe developer applications will make Bose products more valuable and more attractive to prospective purchasers of Bose products. Charging for API access would only increase barriers to developer applications, and thus is not at all something we are considering pursuing at this time.

    With all that said: our goal with the quota is as I mentioned above -- to ensure that non-certified keys are used for personal/home use only. If the 100 calls/day number significantly restricts personal/home use, we could consider expanding it. However, we likely wouldn't make a broad change like that lightly either. Specific examples of the current quota causing a negative impact, and/or other related feedback, are definitely welcome, either here or via email.

  • UpstairsericsUpstairserics Posts: 10Member

    Thanks Zach for taking the time to attempt an answer to my questions.
    While it is still not clear what you are trying to protect against, I applaud your caution.
    My biggest potential problem was the response codes and you have satisfied me that I can still use these effectively.

  • TimDonovanTimDonovan Posts: 4Member

    Bose constantly releases shoddy firmware that breaks functionality, consistently shows zero foresight into UI design and spends years releasing features that competitors already have - yet Bose want to limit missuse of product APIs by EXTERNAL developers? Perhaps after some inwards reflective thinking Bose would come to the realisation that it's their internal development team that's done more to damage their reputation than any external developer ever could.

    Still waiting on permanent grouping (achieved myself using Raspbery Pi's). Still waiting on Alexa skill outside of US (achieved myself using Raspbery Pi's).

Sign In or Register to comment.