Feature Request: Optional userId parameter for /api/session/token endpoint

RastreameMX 21 days ago

Hi,

I would like to suggest the implementation of an optional userId parameter for the /api/session/token endpoint for manager and admin roles.

In Mexico, it is common for logistics companies to manage limited access accounts, often referred to as "mirror accounts," which are functionally equivalent to Traccar's "Read-only" accounts.

However, for many users, it is difficult to keep track of temporary emails and passwords, which are often created with a short expiration period (typically lasting only for the duration of a specific shipment or cargo trip).

While I am aware of the "Share Device" functionality, there are scenarios where a single user needs to monitor two or more GPS units simultaneously. In these cases, accessing a read-only account via a URL with an embedded token is significantly more convenient and user-friendly.

The goal is to streamline the current process, which requires several manual steps, into a single API call. Currently, the procedure is:

1.- Create a read-only account with a real or dummy email and a random password.
2.- Link the authorized units to that account.
3.- Log in to the newly created account.
4.- Navigate to the "Settings" menu (which is no longer visible in recent versions of traccar-web).
5.- Generate the access token and copy it.
6.- Log out of the read-only account.
7.- Log back into the manager account.

In our specific fork of traccar-web, we have already implemented a UI component to generate the token access URL ready to copy, but steps 3, 4, 6, and 7 remain necessary.

screenshot.jpg

Having this parameter available in the API endpoint would help to avoid these 4 steps, and without swapping user sessions.

Best regards.

Anton Tananaev 21 days ago
GV 19 days ago

Screenshot 2026-06-05 at 8.44.49 p.m..png

@RastreameMX create a wizard dialog within the webapp that executes step by step your procedure

RastreameMX 16 days ago

@GV Hi good day.

Yes, that could be an option. Thank you so much for your suggest.

RastreameMX 16 days ago

@GV Hi

I just remembered why the wizard isn't feasible.

To create a token for an account, the current session must be that user's. The idea behind creating tokens externally is so that a manager or admin user can create user tokens without logging into their accounts.

If a wizard is programmed, the session switching can't be avoided, since the wizard would work from the current session (the admin or manager's account). The wizard would have to import the user's session, create the user token, store it, and then return to the admin or manager's previous session, which makes it more complex. I'll still consider it.

I hope the request to add userId to the endpoint will be taken into consideration.

Y por cierto, creo que eres de Monterrey, te iba a responder en español jaja, pero mejor para estandarizar, mejor en ingles.

Saludos.

GV 15 days ago

@RastreameMX you can create a server side function to execute every step for you then your wizard will reflect your http responses. You need a server for that, however to leverage your server functionalities another server is needed as well.

Let me know if i can help you with it.

Si, estoy en Monterrey.

Saludos