Password Reset Token


The current WebAPI v3 references 2 methods of password reset:

  • the account based 'Send reset password email' at ( API Link )
  • the user based 'Reset Password' at{id}/reset-password ( API Link )

I have some concerns/queries.

The Send reset password email is easy to work with, however the issue lies in that the email is out of my control. Users may find an account reset email from Cryptlex confusing when resetting the password on a Web Portal branded for my products.

Ideally I’d like to use the user based Reset Password API, however it requires a password reset token. I can not find an API I can call to retrieve one. My assumption was that I’d generate a personal access token with that ability temporarily, use it and delete it immediately, or that there should exist an API endpoint that generates one, which I can use to generate a temporary URL that can be emailed to the user. However neither of these seem to be the case as I can not find an API call that will return a reset token, and even a Personal Access Token with full access is rejected by the reset password API call as invalid.

Can you advise on how I can go about generating a valid reset token so that I can make use of the User based reset?


Hi Nathan,

Have you considered the customer portal provided by Cryptlex for your customers?

Exposing an endpoint which returns a password reset token will be a big security hole as that would let the user with the permission to generate the token, change anyones password.

Will allowing to set the email body and link suffice?


I’m in the process of building a web portal with extended functionality for a product and thus need a more custom solution to the standard cryptlex customer portal.

My assumption was that as accessTokens for users are scoped to an account, as would a resetToken be scoped to the account that requested the reset. By restricting this generation to only properly scoped Personal Access Tokens it would be up to me to ensure that my web service handles emailing secure links appropriately, just as it’s my responsibility to not let my Admin Token be known so that any user can delete accounts, generate licences etc. Add to this the requirement for userId in the path which is only available to admins and the user, I don’t really see a security risk beyond the one inherent in exposing admin API’s in the first place. If this was not the intention, then can I ask why does the API endpoint exist in the documentation without a method of use?

While not being the most ideal solution, some customisation of the email body/link would be of use.



Hi Nathan,

You have a point, in order to allow custom portals, it’s must to provide an endpoint for generating password reset tokens.

Since, it’s applicability is only for custom portals, which means it is only meant for users and not admins, the endpoint will only allow generating reset token for users with USER role. That will minimise the damage in case access token with permission to generate reset tokens is compromised.

You can expect the endpoint by 25th June, we are releasing a new feature for release management and secure software distribution, it will be released along side.



The requested API endpoint has been added. Please refer to [API docs].(


Thank you very much for that