In Query API Settings, how can I override and define my own custom bearer constant?

How To
1

I need to be able to generate several different API feeds depending on post type or taxonomy from a travel app called Youli.

YouLi uses Bearer authentication (user token) which requires me to use the username and password (which I defined in wp-config.php) to generate a token which is done by Bricks.

Is there a way for me to override this and generate my own token/constants? which I intend to generate using ACF or even manually so instead of getting something like BRX_QUERY_BEARER_TOKEN_OREVQA, I can generate BRX_QUERY_BEARER_TOKEN_LOCATION, etc…

2

I am able to generate my own token outside of Bricks using a snippet I added on WPCodebox (thank you ChatGPT!)

The snippet works when tested on a shortcode and as a Dynamic Tag in Bricks

But using that dynamic tag inside the Query settings still returns an authorization error.
I tried creating a dynamic tag that outputs the raw token as well as one prefixed with bearer
both still don’t work.

3

I ended up just creating a snippet for a custom query and not use the API Query builder to get things working.

4

there is filter hook you can use

add_filter( 'bricks/query_api/headers', 'custom_api_headers', 10, 3);
function custom_api_headers( $headers, $element_id, $query_obj ) {
  if ( $element_id !== 'YOUR QUERY ID' ) {
    return $headers;
  }

  // Add your custom header
  $constant_key = 'YOUR CUSTOM TOKEN CONSTANT';
  $token = defined( $constant_key ) ? constant( $constant_key ) : '';
  if ( ! empty( $token ) ) {
    $headers['Authorization'] = 'Bearer ' . sanitize_text_field( $token );
  }

  return $headers;
}
1 Like
5

This is awesome. I definitely have a use for this on similar projects. I’ll test this later on my local dev.

6

I actually found a better solution for what I intended to accomplish.

Instead of just querying the API directly in Bricks or through a custom query, I created a query that then pulled the data and mapped all the fields to corresponding ACF fields so all data is available and served from the site’s database.

Normally, just hooking up with the API to display dates and snippets of info would just fine, but my current use case requires multiple fields of data for each post in a cpt and having a little downtime with the API source would just blank out entire sections of the layout. Hence the sync to ACF fields.