Improvements for API Query

Feature Requests / Improvements
1

Hey Guys,

I’m working with a client on a Bricks Project where they want to use the API Query feature for retreiving HubSpot data. I’m having two blocking isues.

Firstly:

The acces to the key requires single quotes e.g. {query_api @key:‘properties|event_start_date’}

I need to calculate the dif in seconds between this property and the current timestamp. I can get the timestamp with {current_date:timestamp}, I can convert the datetime to a timestamp with, {format_date @date:‘{query_api @key:‘properties|event_start_date’}’ @from:‘Y-m-d\TH:i:s\Z’ @to:‘timestamp’}}, but can not find a way to dif the two.
So I created a PHP function for echo. This also will not work because both the dynamic property has to be in single quotes and so does the key acess.
{echo:seconds_from_now(‘{query_api @key:’properties|event_start_date’}’)} - will not work.

Perhaps a better solution would be to support dot notation for property access, without needing quotes??

Second issue:

All queries will use the same HS Bearer token. We want to store this in wp-config. However, with the API Query when you select PHP Constant, it generates a different constant for every query. We shoud be able to specify the Constant so we don’t have to create a new constant with teh same value for every API query.

2

Hi @alanblair

Thanks for the detailed explanation

1) Dynamic data + {echo:} limitations

You’re right , {echo:} in Bricks has limitations compared to native PHP, especially when dealing with nested dynamic tags and quotes inside quotes. This particular case isn’t supported.

A possible workaround is to move the logic into a custom PHP function and resolve the dynamic data inside the function itself using bricks_render_dynamic_data(), then return the final result. Example: Retrieve Dynamic Data Like a Pro: Using bricks_render_dynamic_data in Your Custom PHP Functions - Pure Coding Knowledge Sharing Blog

This avoids having to pass complex nested parameters through {echo:}.

The downside, as you mentioned, is that this approach is less flexible if you need to reuse it across different fields.

2) Bearer token constant

What you’re seeing is the current design, each API Query generates its own constant reference.

If you want to reuse the same token without repeating it, you can define a base constant and map it like this

define('MY_SECRET_QUERY_TOKEN', '741852963');

// Get from each query
$my_tokens = [
    'BRX_QUERY_BEARER_TOKEN_Q1W2E3',
    'BRX_QUERY_BEARER_TOKEN_Q4W5E6', // Add more here if more queries using the same constant
];

foreach ($my_tokens as $name) {
    define($name, constant('MY_SECRET_QUERY_TOKEN'));
}

Hope this helps.

Regards,
Jenn

3

Thanks Jen.

I am aware that we can create a PHP function to do this. In my case I want to use it as a conditional. Again I know I can create a custom condition for Bricks. However, it would be much beter if we didn’t have to. It feels like a work around for a limitation that shouldn’t exist.

With the bearer tokens; I did something similar to your code. However, with this client I will end up with about 30 API queries that all use the same token. It would make much more sense if users could specify their own PHP Constant rather than getting assigned a different constant for every query and having to add it to wp-config or alike.