Security in the API

Please understand all of these issues carefully! We value our users' security and will not hesitate to revoke API access to insecure applications.

OAuth must happen in native browsers

For mobile applications: You may NOT use an in-app browser to show the OAuth authentication flow. You must redirect to the native mobile browser, and then receive a redirect back into your app.

We have unescaped data that may contain UNSAFE HTML!

All strings we send you may contain user-generated HTML data (for example, set titles, or words and definitions). We don't render this HTML on our site and you shouldn't render it in your app.

If you are rendering data from our API in an HTML context, you MUST escape its contents. Something equivalent to PHP's htmlspecialchars will work.

Do not override SSL certificate errors

All calls to our 2.0 API happen over SSL to

Do NOT override certificate errors by ignoring them. If you experience errors in recognizing our certificate, please contact us and we'll try to figure out what's happening together.

Access tokens must be handled securely

Access tokens must be handled as securely as passwords and should be stored appropriately. Access tokens must not be stored in cookies, logs, or other insecure places.

Prevent CSRF attacks

Cross-site request forgery (CSRF) is an exploit in which an attacker causes the victim's browser to visit a maliciously constructed URI.

When sending users to the authorization endpoint (, you must send us a non-guessable random value as the state parameter and then verify that one we send you back is the same one you sent us.

Create Set