Sean O Sullivan discusses using APIs to integrate multiple services into a single application accessed with one number. He notes there are good APIs from Facebook, Google, and others that are well-documented but also challenges around security, authentication, dependencies on third parties, and documentation. Authentication can be done through token-based, OAuth, or username/password methods, with token-based preferred.

1. API Experience Sean O Sullivan, CTO [email_address] one number to get things done, hands-free

5. Dial One Number to … Currently 40+ services Interactive, Two-Way service (not just voice to text) Integrates with existing web applications “ sandy” “ Evernote” “ Mosio” “ RTM” “ text” jaiku “ jajah” “ twitter” “ NYT” “ Huff Post” “ tumblr” “ Blogger”

6. One number, many services

7. Technical Overview

8. APIs Lots of API usage in our projects Mobile and Telephony (SMS, on-device APIs, Ribbit …) Classic Web APIs (Google, Facebook, twitter, ping.fm, Jajah…) Also provide our own APIs (not public yet)

9. Good news Good Examples Broadly speaking, many APIs Facebook API Last.fm Google Are well-documented Are well-structured Have associated documentation and code samples

10. Issues Security Each service tends to have a different approach to authentication OpenID, OAuth, Token-based (by user or by service), or worst case username/password Often multiple forms of security supported (Google, Yahoo) Architecture and Design Dependencies on third parties - outages outside your control Is twitter down for everyone or just me? :-) Defensive design and coding (async, failure cases) Other Some services not well documented (Bebo)

11. Authentication Token based, per service Usernames and Passwords don’t need to be stored User control to revoke individual services Your service looks/feels better Oauth or OpenID based Standard with some widespread adoption Google, Yahoo, others… Good documentation, good tools Token based, per user Usernames and Passwords don’t need to be stored Token is at user account level Revoke the token, revoke all services Username / Password Least desirable - YOU have to store username/password

12. Authorisation OpenID Has not as yet seen wide adoption - but will most likely get there (URLs, more complex to grasp for end user) More features than OAuth Cool Off Period Have to protect against brute force auth attacks Need cool-off periods after multiple auth fails e.g. dictionary attack on twitter OAuth We are a Consumer but not yet a provider

13. Sean O Sullivan, CTO [email_address] one number to get things done, hands-free