At AWeber we take data protection seriously, but we also want to make it easy for developers to create cool integrations for our customers to use. In order to achieve both these goals we provide a public API but require developers to use a standard called OAuth to protect the data our API can access.
Since AWeber’s API contains information about lists and subscribers within an account we need strong protection for that data. We chose OAuth because it provides a way for developers to access data while providing both authentication and authorization. In addition, the developer never needs to know the customer’s AWeber login as OAuth uses secure tokens that work in place of the password.
One of the best benefits of OAuth is that it is very easy for a customer to add new integrations -- they simply click a link, sign in, and the rest is magic. They never need a developer account or have to worry about any of the tokens.
How does OAuth work?
AWeber’s API currently uses OAuth 2, which is a multi step process a developer must complete before they can access data in an AWeber account. If you want to see a working example with more detail and code examples check out our API documentation.
The general idea is that the developer tells AWeber a new customer is connecting, then AWeber asks the customer if it’s okay for the developer to access their account data. If the customer approves, the developer is able to obtain keys that allow them to use the API to access data in the customer’s account. If you’ve ever logged in to a website using a social media service the process should feel pretty similar.
There are some restrictions to the things a developer can access. Some things our API just does not allow a developer to look at, billing details are a good example. Other things we require the developer to add additional permissions for, such as seeing subscribers’ email addresses or sending broadcasts. The extra permissions make it clear to the customer that the developer will be allowed to do those things so the customer can make an informed decision about whether to allow the integration access.
Note: At no point in this process should the customer have to create a developer account. Only the developer needs one.
What about OAuth 1?
There is an older version of the OAuth standard called OAuth 1.0a that AWeber's API previously used. Integrations that predate our move to OAuth 2 may continue to use the older version but support for OAuth 1 will be removed in the future. If your integration still uses the OAuth 1.0a version of authentication please plan to move to OAuth 2 as soon as possible. If you have any questions about migration reach out to us at firstname.lastname@example.org and we'll be happy to help!