new_assetid from getExchangeDetails is undefined

[rsnrdk]

Hi everyone!
Any updates on this topic?

Currently the issue is still not fixed, maybe someone figured out another way to reliably determine who sent which item without new asset_id?

I tried to check by Item Certificate but it also changes after trade between users.

[TheMaster]

use the get inventory contents for hte new assetid

[rsnrdk]

8 hours ago, TheMaster said:

use the get inventory contents for hte new assetid

Thank you for the answer!

You mean I should compare my Bot`s inventory before and after the trade and then exctract the new items by asset_ids that i didn`t have before trade right?

[TheMaster]

yes after the trade the new asset id is visible so just set up a inventory poll and u should be good any steam trading bot does inventory poll but be careful not to set the poll too frequent u can get ratelimited very fast.
the old asset id is still in the event handler response so u have both the new id and the old one how i do it is i store a template of the doc in db then use a backfill script to fill in the new asset id.
Hope that helps
Regards

[rsnrdk]

7 hours ago, TheMaster said:

yes after the trade the new asset id is visible so just set up a inventory poll and u should be good any steam trading bot does inventory poll but be careful not to set the poll too frequent u can get ratelimited very fast.
the old asset id is still in the event handler response so u have both the new id and the old one how i do it is i store a template of the doc in db then use a backfill script to fill in the new asset id.
Hope that helps
Regards

Thank you very much!😉

[profesor]

On 8/30/2026 at 4:30 PM, TheMaster said:

yes after the trade the new asset id is visible so just set up a inventory poll and u should be good any steam trading bot does inventory poll but be careful not to set the poll too frequent u can get ratelimited very fast.
the old asset id is still in the event handler response so u have both the new id and the old one how i do it is i store a template of the doc in db then use a backfill script to fill in the new asset id.
Hope that helps
Regards

This would work fine for single item trades but exact pairings of assets still cant be achieved using that.

[rsnrdk]

On 8/31/2026 at 6:23 PM, profesor said:

This would work fine for single item trades but exact pairings of assets still cant be achieved using that.

Why not? When I save the bot`s inventory data before trade, then after the trade i just compare old inventory with the new one.
No matter how much items user will send to my bot.

I mean the logic should work like this:

Inventory assets before trade:
1111
2222
3333

Inventory assets after trade:
1111
2222
3333
4444
5555

the new one are 4444 and 5555.

So the comparison, in theory, should work on DB level.

Currently I did not implement this feature due to a large amount of work on other aspects of my project and Im also trying to figure out how to correctly implement this kind of feature.

I will be very gratefull if you can clarify how to do this

[profesor]

10 hours ago, rsnrdk said:

Why not? When I save the bot`s inventory data before trade, then after the trade i just compare old inventory with the new one.
No matter how much items user will send to my bot.

I mean the logic should work like this:

Inventory assets before trade:
1111
2222
3333

Inventory assets after trade:
1111
2222
3333
4444
5555

the new one are 4444 and 5555.

So the comparison, in theory, should work on DB level.

Currently I did not implement this feature due to a large amount of work on other aspects of my project and Im also trying to figure out how to correctly implement this kind of feature.

I will be very gratefull if you can clarify how to do this

As I was writing an explanation on why that would not work I realised it potentially could depending on your actual needs, so I stand corrected. What I meant is that if someone sends you 5 x AK Redline FT you will not be able to map the old IDs to the new ones unless you track float to match that way. 

Edited yesterday at 06:28 AM by profesor

[rsnrdk]

12 hours ago, profesor said:

As I was writing an explanation on why that would not work I realised it potentially could depending on your actual needs, so I stand corrected. What I meant is that if someone sends you 5 x AK Redline FT you will not be able to map the old IDs to the new ones unless you track float to match that way. 

I tried to visualize my view of how It should work, and actually i cant see any problems except of getting ratelimited due to such operations.
 

Correct me if Im wrong and ask questions Is something is not clear.

[profesor]

3 hours ago, rsnrdk said:

I tried to visualize my view of how It should work, and actually i cant see any problems except of getting ratelimited due to such operations.
 

Correct me if Im wrong and ask questions Is something is not clear.

I guess you are right. As long as you make it airtight to fetch inventory on each accepted trade that could work. It is risky though as certain regions might have access to endpoints while yours might have issues that would create gaps (multiple trades that you sent are accepted by recipients in a short window where your system failed to update). Ridiculous on how they let it happen and not fix it for so long... Another a bit safer method would be mapping float values from incoming and outgoing trades that would be more bulletproof. For assets without float values there is no point in mapping exact units as they are all identical anyways and count book keeping is all you need.

Edited yesterday at 02:20 PM by profesor

[rsnrdk]

47 minutes ago, profesor said:

I guess you are right. As long as you make it airtight to fetch inventory on each accepted trade that could work. It is risky though as certain regions might have access to endpoints while yours might have issues that would create gaps (multiple trades that you sent are accepted by recipients in a short window where your system failed to update). Ridiculous on how they let it happen and not fix it for so long... Another a bit safer method would be mapping float values from incoming and outgoing trades that would be more bulletproof. For assets without float values there is no point in mapping exact units as they are all identical anyways and count book keeping is all you need.

As I said, in theory, my idea should work.
You are absolutely right about the possibility of gaps caused by failed inventory updates. To prevent this, I will save every user`s operation in the database and retry every failed or pending operation until the bot can successfully compare the inventory before and after the trade. Only after the current operation is fully verified will the bot proceed to the next trade.

P.S. I hope this will work not only in theeeooryy lol

[profesor]

On 9/6/2026 at 5:15 PM, rsnrdk said:

As I said, in theory, my idea should work.
You are absolutely right about the possibility of gaps caused by failed inventory updates. To prevent this, I will save every user`s operation in the database and retry every failed or pending operation until the bot can successfully compare the inventory before and after the trade. Only after the current operation is fully verified will the bot proceed to the next trade.

P.S. I hope this will work not only in theeeooryy lol

What happens when you have multiple outbound offers, unless you cap it at one live outbound offer and like you said accept only one trade after a successful update. But all that can be done better like I said by replacing assetId by hashing float value with pattern ID, this is unique and immutable, no gaps ever.

Edited 55 minutes ago by profesor

[rsnrdk]

1 hour ago, profesor said:

What happens when you have multiple outbound offers, unless you cap it at one live outbound offer and like you said accept only one trade after a successful update. But all that can be done better like I said by replacing assetId by hashing float value with pattern ID, this is unique and durable, no gaps ever.

About multiple outbound offers, I will cap it at one live offer per bot at a time:

1) bot sends trade offer
2) bot listens to sentOfferChanged event
3a) if user accepts: save data, mark bot as free, move to next offer in queue
3b) if user doesn`t respond within 5 min: bot cancels the offer, marks itself free, moves on

(p.s. offers are queued via BullMQ, with concurrency capped at 1 per bot)

 

About replacing asset_id by hash.

Good point. I just realised that we can do such operation:

 

The hash is: pattern_id + float + class_id.

Where class_id is the unique category of item, so
we don`t confuse two different items that have the same
float+pattern_id (a very small chance but whatever).

And that kind of functionality doesn`t require comparison before and after every trade which won`t get us ratelimited.

 

But here is one little problem:

In Counter Strike, there are items that don`t have pattern_id and float values... and i`m talking about vanilla-knifes.

So, for normal items the logic above is great fast and reliable, and for vanilla items i don`t know another better solution than compairing inventories before and after trade.

 

Correct me if I`m wrong and thank you for answering.
 

[profesor]

4 hours ago, rsnrdk said:

float+pattern_id (a very small chance but whatever)

Id argue float alone would be enough and pattern id makes it bulletproof. But I guess your addition wont hurt. 

 

4 hours ago, rsnrdk said:

Correct me if I`m wrong and thank you for answering.

I think you don't need all that. Same applies for cases and stickers, they are all identical. If you have 5 vanilla BFK from 5 diff users and one withdraws it does not matter which one you return. Or if someone buys/withdraws a case or vanilla knife you can send whichever one of the tradable stock. All you need to store is the class_id, the count and ownership. Exact unit is irrelevant. 

4 hours ago, rsnrdk said:

And that kind of functionality doesn`t require comparison before and after every trade which won`t get us ratelimited.

 

Ye thats exactly why I suggested that. No possibility of any gaps no additional requests needed no need to implement caps on bots. Its a stopgap/workaround but what can you do when they pull shit like that.

Edited 1 hour ago by profesor

[rsnrdk]

2 minutes ago, profesor said:

Same applies for cases and stickers, they are all identical.

You are right, thats actually doesn`t matter)

 

Thank you for your answers!