this immediately made me think, don't the amazon API limits prevent one from making more than a few thousand calls an hour. Would be very interested to learn how you are countering that. I simply avoid doing anything with Amazon's product api just because of that reason.
How much is it costing you? Charge a markup on that you're happy with rather than picking a number out of thin air?
Also set a healthy free limit, if people are already paying for one product, they're not going to want to pay for an API separately if they just want to make a few calls.
Curious how you set the API call pricing tiers. It seems like this would not be contacted more than several times a day by builds and direct traffic would be free. I can’t imagine 500k calls unless I was serving your data uncached in a client app, but maybe that is a popular use case.
"Im looking for a number that’s affordable for those that want to make a few calls as well as those looking to make thousands of calls without costing them too much."
I've been in this exact scenario before. What we decided on was a generous amount of free API calls included in the standard sales agreement/tier, with anything above 5000 reqs/monthly a bolstered on package.
Of course it will depend on the nature of your calls (are they really going to cost you much, even for many?), the nature of the relationship with your customer, etc. But it was smooth sailing for us.
This kinda sucks BUT I would take it over any Intuit API any day. They have a simple REST API that works exactly like you would expect. I assume if I really need more than 1000 calls a day I could probably contact them and get it raised.
Have you looked at the rate limits? They changed it from 60 calls per user per client ID to 100 calls per minute per client ID. Nothing is getting built with limits that low
Yeah, every time I see that number trotted out I’m just like “and the point is…?”
If there’s an issue with the cost to process that many calls I’m much more suspicious of inefficiency on the API side than the client. Those numbers seem very reasonable.
That is a very high volume, especially for being in development. Here are a few things we have done...
* Use local machine learning models wherever possible.
* Summarize and consolidate calls whenever possible (i.e. reduce token sizes using language analytics).
* Log all calls/responses so it is possible to reuse them and/or to train your ML models. This can cut down on duplicate calls.
* Monitor your API call logs to make sure the system isn't making calls it shouldn't.
* Throttle your calls by introducing delays/bottlenecks in the user interface (by far my least favorite).
* Charge more for your services to decrease demand.
* Contact your account rep and see what options they have to offer with a higher price tier.
This is the problem with usage based pricing. It is very lucrative pricing strategy because it works for lower end of market as well as enterprise users. One way to resolve this is to offer fixed tier based pricing for customers who may be more sensitive to prices and usage based pricing for enterprise clients.
For example.
Starter ($5/mo) - Use up to 100,000 API calls each month.
Growth ($30/mo) - Use up to 1,000,000 API calls each month.
Enterprise ($149/mo) - Use up to 10,000,000 API calls each month. After that, $10 for every 1 million calls.
Wow:) looks like my usage limits for calling recipes exceeded for the day! I have very limited calls, otherwise I'd have to pay out a lot per month to increase. Might have to if more people start using it.
reply