- Architecture
- Wesabe’s API is organized around RESTful principles — each resource has a unique URI (within the context
of the current user), and HTTP verbs are used to specify the action to perform on that resource.
- Client Requirements
- In order to write a client application for Wesabe, you should use a full-featured HTTP client library.
Specifically, your HTTP client should have the following capabilities:
- HTTPS with certification verification
- HTTP verbs: GET, POST, PUT, DELETE
- Basic Authentication
- Redirects
On the example code page, we provide recommendations for libraries
that support all of these capabilities.
- Authentication
- All Wesabe API calls require the user to be authenticated, and every response should be considered in the context of
that user’s data. For example, the request
GET /accounts/1.xml does not refer to an absolute
“Account #1”, but rather the first of the user’s accounts.
Wesabe’s API uses Basic HTTP Authentication for
all requests, with the user’s Wesabe username and password. If the username and password are incorrect, the
server will return a 401 Unauthorized response. The exception to this is that if no username or password are
provided in the Authorization header, a 302 Found will be returned to /user/login.
Session-based authentication (i.e., logging in via the login form and passing the session cookie with each request)
may work, but is unsupported and may have radically different behavior in the future.
- Limitations
- The Wesabe API is currently read-only.
- Changes
- The Wesabe API will change in the future, but we will do our best to communicate backwards-incompatible changes to
API client authors.
Next: Security Considerations »
