Custom authentication
This page explains how to act on behalf of other users with logintokens and refreshtokens.
Use the endpoints described below when you need to execute API requests on behalf of other Filemail accounts. This can be useful when creating an app/UI that integrates with Filemail infrastructure, but requires other users to authenticate. Typical flow:
Use the POST /auth/login providing user email and password.
Store the resulting
refreshtokenfor later use in a secure place (it is valid for 3 months). The resultinglogintoken(valid for 7 days) should be used to authenticate further requests.Include both
x-api-keyandlogintokenin the request headers:x-api-key: mJE5v1zHs.... logintoken: r9BPAFW.....When you issue a request with an expired
logintokenthe server will return401HTTP status code. In that case use therefreshtokenand the POST /auth/refreshtoken endpoint to create a newlogintoken. Note that therefreshtokencan be used only once. You will also get a newrefreshtokenin the response every time you call POST /auth/refreshtoken.
Authenticate as a Filemail user. This operation generates a short-lived (7 days) logintoken and a long-lasting (3 months) refreshtoken. The refreshtoken can be later used to obtain a new logintoken.
Email of the user.
Password matching the user email.
OK
Bad Request
Unauthorized
Too Many Requests
Logout a Filemail user. This operation destroys the logintoken provided in the logintoken header and the associated refreshtoken.
When set to true all the user's logintokens and refreshtokens will be destroyed.
OK
Unauthorized
Generates new logintoken and a new refreshtoken based on an existing refreshtoken (obtained in the login operation). The provided refreshtoken will be destroyed.
A one-time-use refreshtoken obtained from the login endpoint.
OK
Bad Request
Last updated
Was this helpful?
