wouldn't lld be a solution here ?

LLD actually caused this problem in my case. I wrote an LLD script to discover WMI instances given parameters. The two items I need are in different LLD rules.

Then there is still the issue of even if I could compare the two items, there is no way to say "if item.value[1] != item.value[2]" as far as I know. I think ZBXNEXT-1316 -> ZBXNEXT-702 is this request?

Second this.
This is important to use for web sites that require authentication tokens (i.e. authenticate first and get the token, then use the received token for further requests)

For example first HTTP Agent check retrieves an API AUTH token and saves it to a {$USERMACRO}

Then the other HTTP Agent checks use the {$USERMACRO} to connect to a remote API and retrieve data (which is then populated using dependent items).

I tried a workaround of "saving the token to {INVENTORY.TYPE}, but {INVENTORY.*} macros are NOT available for use in HTTP checks.

Funny enough that Zabbix already implements such thing for {INVENTORY.*} macros. To a certain degree this issue can be viewed as a duplicate of ZBXNEXT-336. And unfortunately inventory macros aren't supported as broadly as user macros.

Second this as well,

Sometimes, after user/pass auth, one even needs to pass more than one header/cookie to get access to an API (example: Proxmox API)

Being able to assign an item value to a macro sounds like the solution to this problem (and offer more flexibility). Be it in the way described here or like ZBXNEXT-4744

ZBXNEXT-5065 describes another use case.

This could also solve cases where an item value is required to perform LLD. For example a REST API returns a value which is in fact a pointer to another API object, and in LLD you want to discover the contents of that other API object (as it is related to the current host).

Assigning item data to macros for the use of authentication tokens. How is this going to play out with Zabbix proxies involved? Then ConfigFrequency comes into play i.e. it would take a while for the updated macro to return to the monitoring proxy. Don't we need a multistep httpagent that preserves cookies and returned values, maybe even preprocessed returned values?

In my case, this would be a very useful improvement for many monitors. For example, I need to remake Redis monitoring from a perl script to the zabbix native Redis monitoring.
There are 500+ redis hosts with different passwords in redis.conf. If I could get the password using the zabbix item, then I could very easily use it in redis native items.
Instead, I have to somehow write the password into the zabbix agent config. It's not impossible, but it's not as fast and convenient as the native functionality.

I agree that this would be a very useful thing if implemented in the GUI. 

Perhaps someone could tell me if I am wrong or not. ..... would it not be possible to handle this with the API, specifically the UserMacro class?? 

It would be a possible external script but it would return said value and then be passed to the API for insertion into a macro. 

Again, I agree 100% that this would be a very appreciated addition. 

Hello i'm currently blocked in order to do some API calls. 

I've got one call in order to get the bearer but after I will want put this bearer in a macro in order to use it on other API Calls.

Thanks for your help .

Damien

We now have three major infrastructure "high availability bricks" that we cannot properly supervise with Zabbix, because of the oAuth API logon and tokens. 

Definitively a must for us, either in this way (updating a macro), or in any other way.

any chance to get this in 7.0?

I have created an alternative proposal that should be much easier to implement. Please have a look at ZBXNEXT-9059