Managing UUIDs for Clients

[iwatkot]

Problem: The 3x-ui API does not return the actual Client UUID, it's returning just numerical ID, while for updating a client you'll need to know its UUID.

UPD: Working solution is here:

As @Goosegit11 mentioned earlier, this endpoint returns the actual UUIDs, I can confirm that.

Here's a short snippet of how to obtain Clients with the actual UUIDs (not numeric IDs).

import asyncio

from py3xui import AsyncApi

host = "*********"
username = "*********"
password = "*********"

api = AsyncApi(host, username, password)
email = "iwatkot"


async def test():
    await api.login()
    inbounds = await api.inbound.get_list()
    clients = inbounds[0].settings.clients
    print(clients[0])


asyncio.run(test())

[iwatkot]

Solution: When creating a new Client you will need to save some sort of a map, e.g. e-mail -> UUID. It's up to you how to store this information, but without UUID you will not be able to update the Client.
Code reference:

# First we obtain the user UUID somewhere (e.g. from the database) and pass it into the function above. 

async def set_traffic_limit(telegram_id: int, user_uuid: str) -> None:
    client = await api.client.get_by_email(str(telegram_id)) # Getting the client from API.
    client.id = user_uuid # Updating the client ID to correct UUID (e.g. from the database).
    client.total_gb = gigabytes_to_bytes(10) # Just for reference, setting the traffic limit for a Client to 10 Gb.
    await api.client.update(user_uuid, client) # Updating the client.

[Goosegit11]

You can get it through get_inbounds() method, like that:

inbounds = await get_inbounds()
inbound = inbounds[0]
id = inbound.settings.clients[0].id

[iwatkot]

@Goosegit11 hey!

On the previous versions of 3x-ui I was receiving numerical IDs (1, 2, 3 and so on), not actual UUIDs.

And also, I remember there was inconsistency in the API responses for different protocols, for example some were returning this data, while other - not.

So need to check of now it returns required data everywhere and maybe close this thread.

Sincerely

[Goosegit11]

No no

The thing is, with client.id you get a numeric ID, that's true. Like this:

client: client = await api.client.get_by_email(email)

print(client.id) # 1

But you can also get the client through the get_inbounds() method, and now it has UUID in it.

That's how I got around this problem.

So, you could put something like that to get client UUID by its email

inbounds = await get_inbounds()
inbound = inbounds[0] # get first inbound

client: client = await api.client.get_by_email(email)
num_id = client.id - 1
client_uuid = inbound.settings.clients[num_id].id

[Goosegit11]

oh and that's for vless particularly. haven't tried other protos

I remember there was inconsistency in the API responses for different protocols, for example some were returning this data, while other - not.

[iwatkot]

As @Goosegit11 mentioned earlier, this endpoint returns the actual UUIDs, I can confirm that.

Here's a short snippet of how to obtain Clients with the actual UUIDs (not numeric IDs).

import asyncio

from py3xui import AsyncApi

host = "*********"
username = "*********"
password = "*********"

api = AsyncApi(host, username, password)
email = "iwatkot"


async def test():
    await api.login()
    inbounds = await api.inbound.get_list()
    clients = inbounds[0].settings.clients
    print(clients[0])


asyncio.run(test())

[ra1nbow1]

clients = list(filter(lambda current_client: current_client.email == user_identifier, api.inbound.get_list()[0].settings.clients))
existing_client = clients[0] if clients else None
existing_client.expiry_time = new_expiry_ms
print(existing_client) # email=... enable=True id='a8684b15-abac-48fa-87b5-b9184d0b2074' password='' ...
api.client.update(existing_client.id, existing_client)

What's wrong?
I get ValueError: Response status is not successful, message: Something went wrong! Failed: record not found

New expiry time is valid, client is valid, everything is valid

[SoberSinceToday]

#50 (comment)

[P1f1]

        client = await api.client.get_by_email(str(message.from_user.id))

        if client:
            new_expiry_time = datetime.now() + timedelta(days=30)
            client.expiry_time = int(new_expiry_time.timestamp() * 1000)

            # List of all clients to search for id
            inbounds = await api.inbound.get_list()
            clients = inbounds[0].settings.clients

            # Searching for client id
            id = ""
            for c in clients:
                if client.email == c.email:
                    id = c.id

            try:
                await api.client.update(id, client)
                
            except Exception as e:
                print(client)
                print(id)
                print(e)

What is the problem? I have already found the user's UUID, but the update still doesn't happen?
Error: Response status is not successful, message: Something went wrong! Failed: empty client ID

[SoberSinceToday]

#50 (comment)

[iwatkot]

@ra1nbow1, hey!

I strongly recommend that you check the data you receive from the API before making new requests.
As mentioned earlier, there is inconsistency in responses across different endpoints of the application.
In particular, I checked your case and the methods used and found the following differences.

Client from the inbounds endpoint:

Client from the get_by_email endpoint:

So in your case, this approach indeed won't work because 3x-ui API does not return the inbound ID and I guess the API just doesn't know where to update it.

# Get the Client info from this endpoint.
client = await api.client.get_by_email(client_email)

# Update the needed parameters.
client.id = uuid  # It was obtained from the get_inbounds method or from your database.
client.expiry_time = 9999999999  # <<< your value here

api.client.update(client.id, client)

⚠️ While it's possible to update it in the SDK, I will continue to adhere to the position that SDK is a wrapper for API and does not mutate responses from it.
There is a very simple reason for this: the library has nothing to do with the application itself and therefore, to ensure compatibility and correct operation, it should not mutate responses and return them to the developer exactly in the form in which they were received, with the exception of packaging in models and validating data for convenience.

Otherwise, if the application developers at some point make changes to the API, this will lead to the library losing compatibility with the current version and/or backward compatibility with older versions, which is not the desired outcome for me.

I also expect that this library is used by developers, not end users, and therefore has all the necessary functionality for debugging, checking the values ​​received, as well as checking the payloads sent. In this particular case, I am a little confused by the fact that debugging this issue required two print commands for the responses received from different endpoints.

Despite the fact that I myself, as a developer, do not find it very convenient to work with 3x-ui API, and as a library developer, I also encountered a number of problems due to the inconsistency of the responses, I would also ask you to refrain from any negativity towards the developers of the panel since this is a great open source project, which is handled by a small number of people, and therefore it is quite expected that it may not work perfectly.

I'm going to stop discussing this issue here and encourage developers to take a closer look at the code and data they work with, because I feel like the entire debugging process that was done in these issues was feeding pieces of code and errors into ChatGPT without any attempt to simply see what's inside. And that really upsets me.

@P1f1, I believe your question is similar to what I discussed above.

However, of course, if you find a bug in the library, you can always open an issue, but please first check your payloads, data and refer to the official API documentation, links to each method are in the docstrings.

Best Regards

[ra1nbow1]

Why is your answer so short?

Regards