Instapaper Blog

Full API now available

The full Instapaper API is now available for developers. See the Full API documentation to get started.

I’ve made an unusual decision for it that I’d like to explain. I was reluctant to make a full API before now for a few reasons:

• Instapaper has nontrivial operating costs. If a large number of people used it exclusively via someone else’s API app, and never saw the Instapaper website’s ads or purchased the Instapaper iOS app, I’d lose a lot of money supporting those users.
• One of the biggest uses of a full API is to make mobile apps. But Instapaper already has an iOS app, and this generates nearly all of its income. If someone else’s Instapaper app significantly reduced its sales, or forced it to become free to retain a significant userbase, the service might not survive.

Services with venture-capital backing can keep their APIs free in order to get more users, delaying theoretical profitability to an unspecified future date. For a lot of reasons beyond the scope of this post, that’s not the path I’ve chosen for Instapaper. Since it’s a “normal” business that needs to remain profitable to keep operating, it can’t lose money on a very large number of users indefinitely.

Initially, I came up with two options:

• I could limit the API so it couldn’t be used to make a full-featured Instapaper app. This is the method I’ve implemented before today. But people have evaded this by creating unofficial, fragile apps that scrape the website for data. Such hacks cause problems for everyone.
• I could allow full API access only to developers who agree to pay Instapaper a portion of each app’s sale price. But this is legally and financially more complex and time-consuming than it’s worth for most developers (and for Instapaper), and it imposes a lot of constraints.

Those options aren’t very good. But recently, I came up with a third option that I think is much better:

• Full API access, but only for paid-subscriber accounts. In other words, all developers can use the Full API, but it will only work for customers with Instapaper’s $1/month Subscription memberships.

All previous API functionality will remain free and will work for any account. These methods can only add pages to people’s Instapaper accounts, as implemented in many feed readers and Twitter clients. This part of the API is not changing, and it’s now called the Simple API. To clarify:

• If you have already implemented the Instapaper API in your app, you don’t need to change anything.
• If you’re writing support for Instapaper, and all you need to do is add pages to someone’s Instapaper account, they don’t need to be a Subscriber and you can use the Simple API.
• If your app needs to read data from an Instapaper account, it must use the new Full API, and its customers need to be Subscribers.

Instapaper’s own paid and ad-supported free iPhone and iPad apps in the App Store will continue to work for all customers.

The first app

The first complete Full API app is Stacks for Instapaper, a Windows Phone 7 client. I’d like to thank its developer, Matthieu Guyonnet-Duluc, for helping me find and fix issues with the API. (I’d like to thank the other developers as well, but their apps aren’t finished yet, and I don’t want to blow their cover.)

OAuth 2.0

This version of the Full API requires OAuth 1.0 with xAuth. I’m investigating support for OAuth 2.0 if there’s enough demand. If you’d like to see it, please let me know.

Thank you

Finally, thank you all, developers and customers, for showing so much interest in Instapaper that a full-featured API has become one of its most popular feature requests.

Requiring email and passwords for new accounts

Since its inception, Instapaper has had a famously simple, one-field registration form:

The username can be anything, and there’s no password. You can always set a password in the Account panel, but every new account is registered without one.

To date, 23% of accounts have been registered with usernames that aren’t email addresses, and 82% of accounts don’t have passwords.

But now, after a lot of consideration, I’m changing it to be more traditional:

• New account usernames, and future username changes to existing accounts, must be email addresses. (I don’t care whether they’re real.)
• New accounts will have passwords, and it will no longer be possible to remove passwords on existing accounts. There are no strange requirements — passwords just need to be at least 1 character.

Here’s why:

Problems with non-email usernames

Many of Instapaper’s top support issues are caused by the difference between email addresses and usernames:

• Usernames are much harder to remember than email addresses when people return to the site. Most people have only one email address, but if prompted to create a username, they may choose one of several that they routinely use.
• People often forget whether they signed up with a username or an email address, or they think “username” means the part of the email address before the “@”. They’ll type e.g. “myname@gmail.com” once and just “myname” the next time, resulting in duplicate account registrations and confused customers.
• In some cases, someone has mistakenly logged into someone else’s account because they both chose the same common-word username.
• People with non-email usernames will often forget their passwords, but without knowing their email address, Instapaper can’t send them a reset-password link. Automated password resets aren’t possible at all for the 5% of customers who have passwords but non-email usernames.

There are other drawbacks as well, most notably that I can’t easily create email-based features.

Problems with having no passwords by default

Originally, the rationale behind this was that choosing a password was just a barrier to registration, and since Instapaper isn’t storing any sensitive or valuable data and there’s no reason to share your username publicly, the risks of password-less accounts were too low to matter.

But this creates other problems:

• It’s possible to accidentally log into someone else’s account with a similar username. (See above.) This could result in accidental or intentional destruction or alteration of someone else’s data.
• On login, people are often confused by the presence of the password field since they never set one, and this slows them down, scares them, or discourages them. (The behavior has always been that any entry in the password field for non-passworded accounts would work, which helps, but it’s still a problem.)
• I can’t responsibly encourage people to share their usernames with others unless they’ve set a password, because unscrupulous opportunists could search for these mentions and hijack any non-passworded accounts among them.

Transitioning

Username flexibility and defaulting to no passwords have made registration smoother and easier. But they cause enough problems, especially on future logins, that I no longer believe that they’re worth the registration benefits.

I’ll be updating the login form in the website and the iOS apps with the new requirements in the near future.

Accounts without passwords, or with non-email usernames, will continue to work indefinitely, but I may soon prompt those account holders to set passwords or change their usernames to email addresses.

I know this is a minor inconvenience, but it’s best for Instapaper and its customers. And once the transition is complete, I’ll be able to take advantage and deliver some great new features.