Apps may not use users’ Instapaper data or other personal data in any way that a reasonable person would likely deem “creepy” or otherwise unacceptable. Instapaper reserves the right to decide whether an app’s usage of users’ data is creepy.
Unfortunately one of it's nicest features is the ability to sync and download it's content in the background. I am very disappointed to see that the api tos especially for forbid this.
Combine this with the ability of sites to opt out of Instapaper and the prohibitation against automatically adding things to the user account from an rss feed and my use for Instapaper has pretty much disappeared.
I understand the need for Marco to make money on this, and I hope you make so much money of this that you can swim in it, but frankly the way to do this is not to deliver a crippled service - it's to charge what you are worth, which is far more than one dollar.
The only reason to charge one dollar is to make it to the top of the iphone sales charts. It's not really a viable strategy anywhere else.
* Don't make multiple simultaneous API calls.
* Each thing added must be a result of a specific user action. I'm not sure whether this applies to things retrieved from the API.
Also, the dollar per month is for the subscription service, not the purchase of the Instapaper iOS app. Current Instapaper for iOS app users do not need the subscription service, but users who use apps that use this new API will.
This has the effect that non-iPhone users who want an instapaper client on their phone will have to have a subscription and possibly pay for the mobile app.
In a sense, having an iPhone is akin to having a free subscription (at least for now)
But the second he wants me to pony up, I'm in.
Has anyone here subscribed to Readability yet and added it to your Instapaper account?
Still, a smart move for keeping Instapaper profitable (or at least to keep the API from eating at Instapaper's profits).
That way 3rd party apps can create new keys and issue them to their users transparently.
(2) the post-transaction third party seller has received the express informed consent for the charge from the consumer whose credit card, debit card, bank account, or other financial account will be charged by--
(A) obtaining from the consumer--
(i) the full account number of the account to be charged; and
(ii) the consumer's name and address and a means to contact the consumer;
(B) requiring the consumer to perform an additional affirmative action, such as clicking on a confirmation button or checking a box that indicates the consumer's consent to be charged the amount disclosed
Instead Instapaper should allow developers (or any user) to have more than than one API key/subscription associated with a single card or account. That way if I'm a 3rd party developer, I can create 100 subscriptions myself, and attatch them individually to each program I release to a customer.
The customers information never goes to Instapaper.
My account can be pre-billed if that's what it takes to stay within fincance regulations, but once there's a certain amount prepaid into the account I should be able to create a working subscription key via api.
One benefit of this is that Instapaper doesn't have to worry about dealing with front-line customers---that's the 3rd party developers responsibility. If one customer overuses the API, Instapaper can just cut them off and leave the investigation up to the 3rd party developer.
It's very reasonable for a person to expect that once he paid for the app, he would be able to use it without having a separate subscription paid to a different company.
I'm interested in seeing how these apps clarify this point to users.
Turns out not quick enough. I think this is the best way to approach an API for non VC backed start ups.