/resources/wordpress-abilities-api/
What We Do
Digital Platform MigrationsKey SolutionsManaged ServicesStaffing SolutionsIndustriesProducts
Discovery
Strategic consultancy & project roadmap
Growth Services
On demand development & consultation
Site Maintenance
Annual maintenance. Done for you
QE Services
Testing across SDLC for assured quality
Hosting Migration
Move to a performant hosting with zero downtime
WooCommerce
Enterprise commerce delivered without lock-in
AI
Unlock real use cases and integrations
All Services
A suite of services for any need
Technology STACK
eCommerce
Scale your e-commerce with WooCommerce, integrations, and custom extensions for growth.
EasyEngine
Server management tool that makes using WordPress on Nginx easy.
Web Auditor
Performance Audit & Insights for your Website.
rtMedia
A complete media management plugin for WordPress.
Resources
About Us
CLEAR
Resources Beyond AI: What the Abilities API means for WordPress composability
Topics
On this page
What is a (WordPress) Ability?
What does any of this have to do with AI?
How it works
(Potential) Usage Patterns
Adapter Abstractions
Plugin Dependencies & Ecosystems
Agnostic Integrations
What comes next
Last updated on May 4, 2026
Beyond AI: What the Abilities API means for WordPress Composability
The first piece of the ambitious AI Building Blocks initiative is coming to WordPress 6.9 – and it’s about a whole lot more than AI.
The Abilities API is coming in WordPress 6.9. A key part of the AI Building Blocks initiative, Abilities will help AI systems interact with and integrate into WordPress. But the real story? Beyond the AI hype lies a simple, understated API that is about to revolutionize the way developers build and integrate with WordPress, solving the problem developers have been wrestling with since the platform’s early days: how do you build reliable, maintainable systems when your foundation is a sprawling ecosystem of interdependent plugins?
In this article, we’ll take a look at the new Abilities API, the problems it solves, how it works and can be used (in ways that have nothing to do with AI), and why it’s arguably the biggest DX improvement to WordPress since sliced bread Hooks.
What is a (WordPress) Ability?
To quote the initiative’s announcement post, “The Abilities API transforms WordPress from a collection of isolated functions into a unified, discoverable system.” An Ability is just that: a clearly-defined piece of functionality that your WordPress site is “able” to do.
Abilities are registered once and discoverable and reusable anywhere, and provide strict input and output schemas, validation, and permission checks. Similar to how WordPress Hooks encapsulate the event lifecycle to allow you to write and use code independently from where it’s stored, the Abilities API is more than just DRY principles, but enables coding patterns that support greater interoperability, backward and forward compatibility, and downstream extensibility. As software premised around scalable concepts like “separations of concerns”, the Abilities API marks an appreciated return to form for WordPress, and might just be the feature that finally takes the software from powering 43% of the web to becoming its operating system.
Let’s take a look at this in practice.
Say, for example, we’re an eCommerce plugin in need of a way to create a customer. In the current paradigm of WordPress, we’d create the class/method and then wrap and expose it wherever we need to use it, e.g. via an AJAX response, one or several REST API endpoints, a WPGraphQL mutation, or a public access method to be reused in our codebase. Each implementation would be responsible for its own state and logic, and more importantly, for its own consumption of that core functionality.
/**
* In your plugin logic
*/
private static function do_something(): true|WP_Error {
/* check if the thing can be done, user has perms, etc. */
$customer = MyEcomCustomer::create( $user_args_from_somewhere );
/* do something with the customer. */
}
/**
* As an AJAX/UI action
*/
add_action( 'wp_ajax_no_priv_create_my_ecom_user', static function(): void {
/* validate the `$_POST, the nonce, the payload and then... */
$user = MyEcomCustomer::create( $sanitized_args );
/* then, handle response validation... */
}
/**
* As a REST endpoint
*/
add_action( 'rest_api_init', static function(): void {
register_rest_route( self::MY_REST_NAMESPACE, 'customers', [
'methods' => WP_REST_SERVER::EDITABLE,
'args' => $this->get_args(),
'permission_callback' => [$this, 'permission_callback'],
'callback' => static function( $request ) {
/* conditionaly validatate and prepare the request data before we */
$user = MyEcomCustomer::create( $sanitized_args );
/* then, send back a success response or WP_Error */
},
] );
} );
/**
* Somewhere in userland functions.php
*/
add_action( 'is_this_the_right_hook', static function(): void {
/* do some conditional stuff and hope nothing changed upstream */
try {
SomePlugin\MyEcomCustomer::create( $sanitized_args );
} catch ( $e ) {
/* This is why we disable autoupdates and test each plugin in preprod */
} );
With the Abilities API, all those implementation considerations can be abstracted away:
/**
* Doesn't matter what the context is
*/
$create_customer_ability = wp_get_ability( 'my-plugin/create-customer' );
// The expected input and output are each defined and validated.
// Permissions are checked too.
$customer = $create_customer_ability->execute( $some_input ) {
if ( is_wp_error( $customer ) ) {
/* each implementation can handle this as needed */
}
The abstraction looks simple. The implications run deep.
If you already follow good development practices, this might not seem revolutionary. But the standardization, discoverability, and separation of concerns unlock patterns that weren’t practical before. We’ll explore those shortly. First, let’s address the elephant in the room.
What does any of this have to do with AI?
Nothing… and everything! Whether or not you believe AI is a bubble, there’s no denying the iterative speed of its development, nor the potential impact of generative models and autonomous agents should the correct mix of technological advancement / justifiable use cases be found. The question for WordPress: how do you stay compatible with breakneck innovation when your commitment to backward compatibility risks turning everything into premature tech-debt that’s even harder to drop than an unsupported version of PHP. When you’re responsible for powering such a large portion of the web, the risks of falling for the hype are greater, and thankfully a lot has been learned in the nearly-7 years since WordPress 5.0 was released.
The Abilities API provides an elegant answer. By encapsulating WordPress functionality into a discoverable registry, it then becomes relatively trivial to expose that functionality downstream in, for example, the MCP Adapter experimental plugin, or any future specs that arise such as A2A. It also makes it easy to integrate AI functionality into WordPress: individual AI Experiments don’t need to be manually wrapped in REST endpoints or injected into the Site Editor, Command Palette, or whatever first-or-third-party use case you have – as long as they’re registered, they can be exposed automagically and safely reused.
The stability, parity, and composability afforded by this new API allow 3rd-party code to integrate with each other much more reliably. These needs and considerations aren’t unique to AI, the AI Building Blocks initiative is just one of the first that will employ the pattern.
How it works
Registering an ability is straightforward. Say, our eCommerce plugin needed to be able to create orders once a user purchased a product.
add_action( 'wp_abilities_api_init', static function (): void {
wp_register_ability(
'my-plugin/create-order' // The unique ability name.
[
'label' => __( 'Create order', 'my-plugin' ),
'description' => __( 'Creates a sales order.' ),
'input_schema' => self::get_input_schema(), // WP JSON Schema to validate input.
'output_schema' => self::get_output_schema(), // WP JSON Schema to ensure/validate output.
'execute_callback' => static function ( array $input ) {
// The logic you want to run.
// Take the schema-validated input, and make sure to return the the expected output or a WP_Error
},
'permission_callback' => [ self::class, 'get_permission_callback' ] // whether the ability should run given the input.
'meta' => [
'show_in_rest' => true // Makes the ability discoverable via the REST API.
...self::get_metadata() // Arbitrary custom metadata
]
);
} );
The input_schema and output_schema define and enforce the data shapes, while execute_callback will be run by the Ability after a central permission_callback check passes. Meanwhile, the label, description, and meta provide semantic information.
Once registered, Abilities can be retrieved via a call to wp_get_ability( ‘my-plugin/create-order’ ), allowing access to the WP_Ability class and its public methods.
(Potential) Usage Patterns
Now that you’re up-to-date on the basics, let’s start exploring the different ways and possible coding patterns that a fully-featured Abilities API will help you adopt.
Note: The coding patterns below are purely illustrative and intended to demonstrate potential usage in various implementations. Nothing that follows is meant to be prescriptive.
Adapter Abstractions
When “everything” is an Ability at its core, the obvious use case is adapting that abstraction to whatever e last-mile implementation we need. You can see that at work in the MCP Adapter plugin, but since I promised to try and keep this article AI-free, let’s theorycraft a basic REST adapter.
Here’s manually adapting an ability to a single REST endpoint:
register_rest_route(
'my-plugin/v1',
'add-to-cart',
array(
'methods' => \WP_REST_Server::EDITABLE,
'callback' => static function ( \WP_REST_Request $request ) {
$params = $ability = wp_get_ability( 'my-plugin/add-to-cart' );
if ( ! $ability ) {
return new \WP_Error( 'rest_no_ability', __( 'The ability is not registered.', 'my-plugin' ), array( 'status' => 500 ) );
}
try {
// Assuming we're compatible with the ability output schema, otherwise we'd "adapt" the params first.
$result = $ability->execute( $request->get_params() );
if ( is_wp_error( $result ) ) {
// Give it a status code.
return new \WP_Error(
$result->get_error_code(),
$result->get_error_message(),
array_merge( $result->get_error_data(), array( 'status' => 500 ) )
);
}
// Assuming we're compatible with the ability output schema, otherwise we'd "adapt" it.
// You could even call a follow-up ability _or several_ before returning the final result.
return new \WP_REST_Response( $result, 200 );
} catch ( \Throwable $e ) {
// Assuming that the permission check means it's safe to expose the message.
return new \WP_Error( 'rest_ability_execution_failed', $e->getMessage(), array( 'status' => 500 ) );
}
},
'permission_callback' => static function () {
// No need to duplicate the Ability API check here, just be additive per your REST-specific requirements.
return current_user_can( 'my_plugin_can_use_rest', '/add-to-cart' );
},
)
);
No big deal, right? If you’re following good coding patterns, you’re probably already doing something similar. But we’re not here to write individual implementations, we’re creating an adapter. Let’s register all our abilities automatically:
class MyRestAdapter extends \WP_REST_Controller {
/**
* {@inheritDoc}
*/
public function register_routes(): void {
// In the future, the Abilities API will support querying/filtering, but for now we need to do it ourselves.
$abilities = array_filter(
wp_get_abilities(),
static function ( $ability ) {
return str_starts_with( $ability->get_name(), 'my-plugin/' );
}
);
// Loop through and register endpoints for each ability.
foreach ( $abilities as $ability ) {
// Even though we're abstracting we can still implement granularity. For example.
if ( in_array( $ability->get_name(), array_keys( MyRestEndpointFactory::$endpoints ) ) ) {
// Get this from a manual class overload.
MyRestEndpointFactory::$endpoints[ $ability->get_name() ]->register_routes();
continue;
}
// We can also use meta to determine how to expose the ability.
// As more use cases arise, more global meta conventions will be established.
$meta = $ability->get_meta();
$name = $ability->get_name();
// For example, we can skip abilities we choose to label "private".
if ( ! empty( $meta['my_plugin_settings']['private'] ) ) {
continue;
}
// Or use it to determine the default adapter behavior.
register_rest_route(
'my-plugin/v1',
$this->prepare_endpoint_name( $name ), // Custom function to strip and transform.
[
'methods' => $this->map_meta_to_rest_methods( $meta ), // Custom function to determine WP_REST_Server method type(s).
// Assuming the ability schema is identical to what we want for REST.
'args' => $ability->get_input_schema(),
// If it isnt, we can extend the WP_REST_Controller methods to adapt it. E.g.
'schema' => $this->get_public_item_schema( $name ),
// or polymorphically:
'callback' => ! empty( $meta['my_plugin_settings']['is_single'] ) ? $this->get_items( $name ) : $this->get_item( $name ),
'permission_callback' => static function () use ( $ability ) {
// No need to duplicate the Ability API check here, just be additive per your REST-specific requirements.
return current_user_can( 'my_plugin_can_use_rest', '/' . str_replace( 'my-plugin/', '', $ability->get_name() ) );
},
]
);
}
}
/**
* {@inheritDoc}
* Just an OOP abstraction example. This is not prescriptive.
*
* @param string|null $ability_name
*/
public function get_public_item_schema( ?string $ability_name = null ): array {
if ( empty( $ability_name ) ) {
parent::get_public_item_schema();
}
// Use the output schema for the ability.
// But if you wanted you could adapt things here.
return ( wp_get_ability( $ability_name ) )->get_output_schema();
}
}
At its core, this is just a `foreach()` loop mapping Abilities to `register_rest_route()`. Everything else is an illustrative boilerplate. But notice what just happened: you can now make every Ability as slim or complex as needed, and they’re automatically exposed through REST.
How about we register the exact same abilities as data to WPGraphQL at the same time as REST:
class MyEverythingAdapter {
public function adapt_all_the_things(): void {
// In the future, we'll be able to search/query/filter abilities, but for now I'll do it my manually.
$abilities = array_filter(
wp_get_abilities(),
static function ( $ability ) {
return str_starts_with( $ability->get_name(), 'my-plugin/' );
}
);
// Loop through and register endpoints for each ability.
foreach ( $abilities as $ability ) {
// Map the WP_Ability props and meta to rest args, and call register_rest_route()
$this->register_to_rest( $ability );
$this->register_to_graphql( $ability );
// And any other APIs you want to adapt to.
}
}
/**
* I'm not here to teach you how to use WPGraphQL, this is all illustrative
* and uses imaginary stubs.
*
* @param \WP_Ability $ability The ability to register.
*/
private function register_to_graphql( \WP_Ability $ability ): void {
// Like before, we use the meta to determine our adapter's behavior.
$meta = $ability->get_meta();
$graphql_type = $this->ability_type_to_graphql_type( $meta['my_plugin_ability_type'] );
switch( $graphql_type ) {
case 'field' {
register_graphql_type(
$this->prepare_gql_type_name( $ability->get_name() ),
$this->map_gql_schema_to_graphql_type( $ability->get_output_schema() ),
);
register_graphql_field(
'RootQuery',
$this->prepare_gql_field_name( $ability->get_name() ),
// This is where you'd expose the input args, and use $ability->execute() to resolve.
$this->map_ability_to_field_args( $ability ),
);
}
case 'connection' {
register_graphql_connection_type(
$meta['my_plugin_settings']['graphql']['fromType'],
$this->prepare_gql_field_name( $ability->get_name() ),
$this->map_ability_to_connection_args( $ability ),
);
}
case 'mutation' {
register_graphql_mutation(
$this->prepare_name_for_graphql( $ability->get_name() ),
$this->map_ability_to_graphql_mutation_args( $ability )
);
}
}
}
}
The specificities of WPGraphQL’s arguments aside, what used to require boilerplate across a dozen SOLID classes now maps centrally. The tech debt savings compound as your needs grow.
Plugin Dependencies & Ecosystems
WordPress’s greatest strength is its vast plugin ecosystem, but those plugins are also the biggest source of risk and tech debt. More fragile are the first- and third-party plugin “extensions” that rely on a compounding lie of non-semantic versioning. Even enterprises with robust deployment CI and per-page visual regression and E2E suites think twice before relying on more than a handful of interdependent plugins to save the costly nightmare of trying to keep them up-to-date without breaking.
The Abilities API provides the encapsulation needed to reliably use 3rd-party functionality, without worrying about the release hygiene and code-quality “best practices” of every plugin in your stack:
/**
* Uses the ability to process our custom coupon, so we don't need to care about state or context.
*
* @param array $ability_input The input required (and validated) by the underlying ability.
* @param array $coupon_data The data specific to our coupon extension.
*/
private function add_coupon_to_cart( array $ability_input, array $coupon_data ): SomeCartDto | WP_Error {
$update_cart_ability = wp_get_ability( 'my-commerce/update-cart' );
if ( ! $update_cart_ability instanceof \WP_Ability ) {
// Handle the error, maybe log it or notify the admin.
$this->logger->error( 'The ability is missing.' );
return;
}
// Validate our local "extension" data, the rest isn't our concern.
$this->validate_coupon_data( $coupon_data );
return $update_cart_ability->execute( array_merge(
$ability_input,
[
'my_plugin_coupon_data' => $coupon_data,
]
) );
}
Instead, by relying on predictable input and output schema we can maintain a “stateless” separation of concerns, without worrying about global state, race conditions, or other implementation details. In other words, we’re depending on the contract, not the implementation.
We can also compose different abilities together with the same levels of confidence:
public function register_ability(): void {
wp_register_ability(
'my-plugin/renew-subscription',
array(
'label' => __( 'Renew Subscription', 'my-plugin' ),
'description' => __( 'Renews a subscription for a provided customer.', 'my-plugin' ),
// Internally, we can inherit and merge schemas from the abilities we use.
'input_schema' => $this->get_input_schema(),
'output_schema' => $this->get_output_schema(),
'callback' => static function ( array $input ) {
// E.g. only allow renewal if the customer is active.
$customer_handler = wp_get_ability( 'rtcommerce/customers' );
if ( $customer_handler->execute(
[
'user_id' => $input['user_id'],
// There's lots of theoretical ways to compose an ability.
'action' => 'check-status',
]
) !== 'active' ) {
return new \WP_Error( 'my_plugin_customer_inactive', __( 'Your account has been disabled and cannot be automatically renewed. Please contact support.', 'my-child-plugin' ) );
}
// Not everything has to be an ability.
$subscription_data = MyPlugin::get_subscription_by_id( $input['subscription_id'] );
// Use a different ability to prepare.
$add_subscription_to_cart_ability = wp_get_ability( 'my-plugin/add-subscription-to-cart' );
// Assumedly this action also applies taxes, shipping, etc using the underlying commerce ability.
$cart = $add_subscription_to_cart_ability->execute(
[
'user_id' => $input['user_id'],
'subscription' => $subscription_data,
],
);
$create_order_ability = wp_get_ability( 'rtcommerce/create-order' );
return $create_order_ability->execute(
[
// The input_schema made it obvious that this uses a customer ID
// and not a user ID.
'customer_id' => $input['customer_id'],
'order_data' => $cart->to_array(),
'status' => 'pending',
],
);
},
'meta' => $this->get_ability_meta(),
),
);
}
Each Ability validates its own input and output. You orchestrate them without worrying about data validation because we can rely on the Ability API to do it for us.
Agnostic Integrations
While the last section showed how the Abilities API helps enforce a separation of concerns from even the shakiest of external codebases, it also makes it easier to add support for multiple competing plugins. For example:
/**
* Callback for `my-events-plugin/rsvp` ability.
*
* Doesn't care what ecommerce plugin you use, it just RSVPs the user for the event.
*
* @param array $input The input data for the ability.
*
* @return \MyRsvpDataModel|\WP_Error
*/
private function rsvp_ability_callback( array $input ) {
// E.g. a user-extendable factory of input/output mappers.
$supported_checkouts = apply_filters(
'my_supported_checkouts',
array(
'moocommerce/checkout' => array(
'map_input' => static fn( array $input ): array => $this->map_input_for_moo( $input ),
'map_output' => static fn( $output ): MyRsvpDataModel => $this->map_output_from_moo( $output ),
),
'pdd/process-order' => array(
'map_input' => static fn( array $input ): array => $this->map_input_for_pdd( $input ),
'map_output' => static fn( $output ): MyRsvpDataModel => $this->map_output_from_pdd( $output ),
),
'rtcommerce/buy' => array(
'map_input' => static fn( array $input ): array => $this->map_input_for_rt( $input ),
'map_output' => static fn( $output ): MyRsvpDataModel => $this->map_output_from_rt( $output ),
),
),
);
$current_checkout = $supported_checkouts[ $this->detect_current_checkout() ];
$this->do_my_rsvp_stuff( $input );
// Process the input.
$order = $current_checkout['map_output'](
$current_checkout['map_input']( $input )
);
if ( is_wp_error( $order ) ) {
return $order;
}
$this->do_more_rsvp_stuff( $order['customer_id'], $input );
}
Just as with the earlier adapter example pattern, the predictability allows us to simplify and standardize around thin and centralized compatibility layers. Since we only need to care about the API contract when using an Ability, integrations can be maintained in isolation instead of leaking tech debt throughout your app.
You can even build polymorphic extensibility into parent plugins, allowing “plug-and-play” extensions that work as seamlessly as if they were core features:
$args['checkout_callback'] = static function ( array $input ) {
// Inside, there's a mapper + apply_filters() for extensibility.
// Since we're the plugin we can assert the shared input/output schema.
$cart_ability = $this->get_browser_cart_ability();
$shipping_calculator_ability = $this->get_shipping_calculator_ability();
$process_payment_ability = $this->get_process_payment_ability();
// Input schemas don't stop bad API design, just ensure predictability.
$user = get_user_by( 'id', $input['user_id'] ) ?: get_user_by( 'email', $input['user_data']['email'] );
if ( ! $user ) {
$create_user_ability = $this->get_create_user_ability();
$user = $create_user_ability->execute(
array(
'user_data' => $input['user_data'], // ensured by our input_schema.
)
);
// Only users can checkout in our ficticious plugin.
if ( is_wp_error( $user ) ) {
return $user;
}
}
$shipping_fee = $shipping_calculator_ability->execute(
array(
'cart' => $cart_ability->execute( $input['cart_items'] ), // for the weight etc.
'shipping_address' => $input['shipping_address'], // ensured by the input_schema.
)
);
// The order object is used to populate the final confirmation by the payment process.
$pre_order = $process_payment_ability->execute(
array(
'user' => $user,
// Make sure the cart is up-to-date, and whatever composed abilities it uses.
'cart' => $cart_ability->execute( $input['cart_items'] ),
'fees' => array(
'shipping' => $shipping_fee,
),
)
);
return array(
'callback_url' => apply_filters( 'my_ecom_plugin/checkout/gateway_endpoint', $pre_order['gateway_endpoint'], $ability->get_name(), $pre_order ),
'callback_args' => $pre_order['gateway_args'], // Output schemas can be inherited.
'user_id' => $user->ID,
);
};
Here, too, we can choose to leverage meta or even infer what ability we want to use.
private function optimize_media( array $input ) {
// Finding the right ability can be considered an ability too.
$find_optimizer_ability = wp_get_ability( 'my-plugin/find-media-optimizer' );
$optimizer_ability = $find_optimizer_ability->execute( array( 'media_type' => $input['media_type'] ) );
if ( is_wp_error( $optimizer_ability ) ) {
return $optimizer_ability;
}
// Now we have the optimizer ability, we can use it to optimize the media.
$optimize_ability = wp_get_ability( $optimizer_ability );
$optimization_data = $optimize_ability->execute( $input );
if ( is_wp_error( $optimization_data ) ) {
return $optimization_data;
}
// Log the optimization savings for any o11y abilities.
// We need to filter the results of `wp_get_abilities()` ourselves until filtering support is added.
$o11y_abilities = $this->get_abilities_by( array( 'meta' => array( 'type' => 'o11y' ) ) );
foreach ( $o11y_abilities as $ability ) {
// The assumption here is that all 'o11y' abilities have the same schema.
// If the didn't, you'd map them to the correct shape.
$ability->execute(
array(
'message' => __( 'Media optimized using ', 'my-plugin' ) . $optimizer_ability,
'optimization_data' => $optimization_data,
)
);
}
}
There is no need to juggle multiple entry points or to understand the minutiae of a plugin’s custom hook order. It’s all just contracts and composition.
What comes next
We’re far from a future where all WordPress features are just implementation wrappers around interoperable, agnostic Abilities. Even after the Abilities API ships in WordPress 6.9, it will take time for the ecosystem to coalesce around shared patterns and best practices. Backwards and forwards compatibility concerns mean we’ll first see a growing subset of Core Abilities long before any existing functionality is refactored to use them. And that’s fine. The API doesn’t require WordPress to change; it creates space for developers to build differently when they’re ready.
What we can do, however, is review, test, and leave feedback. The examples above hopefully got you thinking about some possible ways we can architect a composable future. Share those ideas, expectations, and real-world experiments with the project contributors, and start preparing your mind – and codebases – to think composably Where are you duplicating logic? Where do your integrations and plugin dependencies feel the most fragile?.
Even if AI proves to be a bubble and pops tomorrow, WordPress is going nowhere. The future is coming faster than ever, and it’s Abilities all the way down.
Credits
David Levine
Author
David Levine
Author
David Levine is a Senior WordPress Engineer and Product Lead at rtCamp with a background that few engineers in the WordPress space can claim. A WordPress Core Contributor across multiple releas…
Aviral Mittal
Editor
Aviral Mittal
Editor
Aviral Mittal is the Chief Marketing Officer at rtCamp, where he established and leads the marketing function, building and growing a team of 20+ specialists across content, SEO, design, and growth…
Good Work. Good People.
Industry partnerships
Compliance certifications
United States India
© rtCamp Inc. since 2009. All rights reserved.
Terms of Service · Privacy Policy · Trust Center
Company
Solutions
Subscribe to our newsletter and get a few email updates every month.
United States India
© rtCamp Inc. since 2009. All rights reserved.
Terms of Service · Privacy Policy · Trust Center
Cookie Consent
We value your privacy
We use cookies to give you the best possible experience. By clicking “Accept,” you consent to our use of cookies to improve site functionality, analyze usage, and personalize content and communications. Your privacy matters to us, and we are committed to handling your data responsibly and transparently. Please check our Privacy Policy for more details.
Manage PreferencesDon’t AllowAllow All
Why do we use cookies?
×
By clicking "Accept" or "Decline All" at the bottom, you consent to the use of cookies and other tools as described in our Cookie Policy in accordance with your settings and accept our Terms of Service.
Toggle EssentialEssential
Essential cookies enable basic functions and are necessary for the proper function of the website.
Name
Description
Duration
Geolocation Config
This cookie is used to store the consent settings based on the visitor's location.
30 days
Cookie Preferences
This cookie is used to store the user's cookie consent preferences.
30 days
Toggle CloudFlareCloudFlare
CloudFlare provides web performance and security solutions, enhancing site speed and protecting against threats.
Service URL: developers.cloudflare.com (opens in a new window)
Name
Description
Duration
cf_clearance
Whether a CAPTCHA or Javascript challenge has been solved.
session
Toggle CommentsComments
These cookies are needed for adding comments on this website.
Name
Description
Duration
comment_author
Used to track the user across multiple sessions.
Session
comment_author_email
Used to track the user across multiple sessions.
Session
comment_author_url
Used to track the user across multiple sessions.
Session
Toggle GodamGodam
GoDAM" is primarily a specialized WordPress plugin and media management service designed to enhance video hosting, marketing, and asset management directly within the WordPress dashboard.
Service URL: godam.io (opens in a new window)
Name
Description
Duration
user_image
Temporarily stores the path to the user's avatar or profile picture for quick rendering in the website header.
session
user_id
Stores the numerical ID of the logged-in user to maintain session continuity and basic site operations.
session
full_name
Stores the logged-in user's display name to personalize the site interface without needing database queries.
session
system_user
First-party cookie used to store basic application state identifying the current system user role.
session
sid
A generic session ID cookie used to maintain user state and functionality as the visitor navigates through the site.
session
Toggle Google reCAPTCHAGoogle reCAPTCHA
Google reCAPTCHA helps protect websites from spam and abuse by verifying user interactions through challenges.
Name
Description
Duration
_GRECAPTCHA
Google reCAPTCHA sets a necessary cookie (_GRECAPTCHA) when executed for the purpose of providing its risk analysis.
179 days
Toggle Google Tag ManagerGoogle Tag Manager
Google Tag Manager simplifies the management of marketing tags on your website without code changes.
Name
Description
Duration
cookiePreferences
Registers cookie preferences of a user
2 years
td
Registers statistical data on users' behaviour on the website. Used for internal analytics by the website operator.
session
Toggle StatisticsStatistics
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Toggle Factors AIFactors AI
Factors.ai is a B2B account intelligence and marketing analytics platform that helps Go-To-Market (GTM) teams identify anonymous website visitors, track buyer journeys, and measure the ROI of marketing campaigns.
Service URL: www.factors.ai (opens in a new window)
Name
Description
Duration
_fuid
It is sent to capture session details and track user behavior across your website to provide behavioral data and intent signals.
1 Year
Toggle Google AnalyticsGoogle Analytics
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Service URL: policies.google.com (opens in a new window)
Name
Description
Duration
FPGSID
Stores a session or user identifier to track how visitors interact with a website. This helps Google Analytics measure website performance, user engagement, and usage patterns.
Session
FPLC
Used by Google Analytics to link visitor interactions and sessions across multiple related domains.
20 hours
FPID
A server-side Google Analytics cookie used as an alternative user identifier when third-party cookies are restricted.
2 years
_ga
ID used to identify users
2 years
_ga_
ID used to identify users
2 years
Toggle Jetpack StatsJetpack Stats
Jetpack's built-in visitor analytics. It records page views, referring sites, search terms, and outbound link clicks, and also carries the shared visitor-tracking library used by Jetpack Instant Search and WooCommerce Analytics.
Service URL: automattic.com (opens in a new window)
Name
Description
Duration
tk_aip
Stores a list of anonymous visitor IDs so they can be merged into one identity once a visitor is recognized.
Up to 5 years
tk_tc
Used once per page load to work out which cookie domain the Tracks library should use, then removed as soon as it's read back.
Session (deleted immediately after use)
tk_qs
Queues analytics events for Jetpack's Tracks library so none are lost if the page closes before they can be sent.
30 minutes
tk_ai
Stores a randomly-generated anonymous visitor ID so Jetpack's Tracks analytics library can link tracking events to the same visitor.
Session in wp-admin; up to 5 years on the frontend
Toggle Microsoft ClarityMicrosoft Clarity
Clarity is a web analytics service that tracks and reports website traffic.
Service URL: clarity.microsoft.com (opens in a new window)
Name
Description
Duration
CLID
Identifies the first-time Clarity saw this user on any site using Clarity.
12 months
ANONCHK
Indicates whether MUID is transferred to ANID, a cookie used for advertising. Clarity doesn't use ANID and so this is always set to 0.
Session
_clck
Persists the Clarity User ID and preferences, unique to that site is attributed to the same user ID.
12 months
_clsk
Connects multiple page views by a user into a single Clarity session recording.
12 months
Toggle Parse.lyParse.ly
Parse.ly is a content analytics platform that helps publishers optimize audience engagement and content performance.
Name
Description
Duration
cookies.js_dtest
This cookie determines whether the browser accepts cookies.
session
_parsely_session
JSON document storing information identifying a browsing session according to Parsely’s proprietary definition
30 minutes
_parsely_visitor
JSON document uniquely identifying a browser and counting its sessions
13 months
Toggle SalespanelSalespanel
Salespanel is a B2B marketing and sales software that identifies, tracks, and qualifies website visitors and leads in real-time using first-party data. It helps businesses monitor customer journeys, score leads based on behavior, and syncs this data with CRMs (like Pipedrive or HubSpot) to improve conversion rates.
Service URL: salespanel.io (opens in a new window)
Name
Description
Duration
track_uid
Identify and tracking a lead
12 moths
Toggle MarketingMarketing
Marketing cookies are used to follow visitors to websites. The intention is to show ads that are relevant and engaging to the individual user.
Toggle Bing / MicrosoftBing / Microsoft
Bing, powered by Microsoft, is a search engine providing web, image, video, and map search capabilities.
Name
Description
Duration
MR
Used to collect information for analytics purposes.
6 months
ANONCHK
Used to store session ID for a users session to ensure that clicks from adverts on the Bing search engine are verified for reporting purposes and for personalisation
10 minutes
SM
Used by Microsoft in synchronizing the MUID across multiple Microsoft domains to track users for advertising.
session
MUID
Identifies unique web browsers visiting Microsoft sites. These cookies are used for advertising, site analytics, and other operational purposes.
1 year
Toggle DoubleClick/Google MarketingDoubleClick/Google Marketing
A comprehensive digital advertising platform for managing campaigns, optimizing performance, and analyzing audience data.
Name
Description
Duration
IDE
This cookie is used for targeting, analyzing and optimisation of ad campaigns in DoubleClick/Google Marketing Suite
2 years
ar_debug
Store and track conversions
Persistent
Toggle LinkedInLinkedIn
LinkedIn is a professional networking platform for job seekers, employers, and industry connections.
Name
Description
Duration
bscookie
Used by LinkedIn to track the use of embedded services.
1 year
AnalyticsSyncHistory
Used to store information about the time a sync with the lms_analytics cookie took place for users in the Designated Countries
30 days
bcookie
Used by LinkedIn to track the use of embedded services.
1 year
li_sugr
Used to make a probabilistic match of a user's identity outside the Designated Countries
90 days
lidc
Used by the social networking service, LinkedIn, for tracking the use of embedded services.
1 day
UserMatchHistory
Used by LinkedIn Ads to synchronize and match user IDs across different ad networks and data providers.
30 days
Toggle LinkedIn InsightLinkedIn Insight
LinkedIn Insight is a web analytics service that tracks and reports website traffic.
Service URL: www.linkedin.com (opens in a new window)
Name
Description
Duration
li_sugr
Used to make a probabilistic match of a user's identity.
90 days
lidc
Used for routing and session management.
24 hours
Toggle LiveIntentLiveIntent
LiveIntent provides a platform for email advertising and identity-driven marketing solutions.
Name
Description
Duration
_lc2_fpi_js
Companion cookie to _lc2_fpi used by JavaScript to facilitate cross-domain ad tracking and user identification.
1 year
_lc2_fpi
First-party tracking cookie usually associated with LiveRamp to identify users across devices for targeted advertising.
1 Year
_li_ss
Sets a unique ID for the visitor, that allows third party advertisers to target the visitor with relevant advertisement. This pairing service is provided by third party advertisement hubs, which facilitates real-time bidding for advertisers.
1 month
lidid
Collects data on visitors' behaviour and interaction - This is used to make advertisement on the website more relevant. The cookie also allows the website to detect any referrals from other websites.
2 years
Toggle Cookie PolicyCookie Policy
You can find more information in our Privacy Policy.
Allow AllDecline All
Accept