Setting up? Start with Keep existing WPGetAPI code working.

All surfaces below are controlled by the single WPGetAPI Compatibility toggle (HuxxConnect → Settings, setting key wpgetapi_compat, default off). Sources: src/Compat/WPGetAPIBridge.php, src/Compat/WPGetAPIFunctions.php, src/Compat/WPGetAPIFunctionCompat.php (free) and src/Compat/WPGetAPIPostCreatorBridge.php (Pro).

wpgetapi_endpoint()#

function wpgetapi_endpoint( string $api_id = '', string $endpoint_id = '', array $args = array() )

Source: src/Compat/WPGetAPIFunctions.php. Defined only when WPGetAPI has not already defined it. Returns false only when the toggle is off or $api_id / $endpoint_id is empty; otherwise executes through HuxxConnect and returns the response data ('' for format=no_display). Execution failures — unknown API or endpoint, deactivated API, blocked execution, HTTP errors — return an ErrorResponse object, not false, so legacy false === $result checks do not catch them. With debug set, HTTP/parse failures are returned in the array form instead; pre-request failures (unknown API or endpoint, deactivated API, blocked execution) return the object even with debug set.

Parameters#

Supported $args keys#

Example#

$products = wpgetapi_endpoint( 'demo_api', 'get_products', array(
    'keys' => 'products,0,title',
) );
echo esc_html( $products );

Output:

Essence Mascara Lash Princess

Each call also logs a one-per-request migration hint in Settings → WPGetAPI Compatibility, e.g. consider updating to huxx_api('demo_api', 'get_products') — see Template functions for the native API.

wpgetapi_api_to_posts()#

function wpgetapi_api_to_posts(): array

Source: src/Compat/WPGetAPIFunctions.php. Stub only: always returns an empty array. When the toggle is on, it logs a warning that this WPGetAPI Pro add-on function is not supported; the HuxxConnect equivalent is Pro’s Post Creator (Map API fields to posts).

Shortcode aliases#

Source: src/Compat/WPGetAPIFunctionCompat.php::register_shortcodes(). Registered only when the toggle is on and WPGetAPI itself is not active.

Attribute handling: api_id / endpoint_id (and short forms api / endpoint) are slug-normalized; keys is translated per “Keys normalization”; all other attributes pass to the native renderer.

Example#

[wpgetapi_endpoint api_id="demo_api" endpoint_id="get_products" keys="products,0,title"]

Output:

Essence Mascara Lash Princess

Keys normalization#

WPGetAPI keys values are rewritten to native keys syntax before extraction (WPGetAPIFunctionCompat::normalize_wpgetapi_keys()):

Bridged filters — request/response lifecycle (free)#

Source: src/Compat/WPGetAPIBridge.php (HOOK_MAP). Each HuxxConnect hook carries a priority-999 listener that fires the WPGetAPI filter only when it has registered callbacks, passing an adapter object in place of $wpgetapi.

Validation: if a callback’s return fails the per-hook structural rules, the bridge reverts to the original value and records a warning (visible in Settings → WPGetAPI Compatibility; flushed at shutdown). Unchanged returns skip validation.

Example#

add_filter( 'wpgetapi_final_url', function ( $url, $wpgetapi ) {
    if ( 'demo_api' === $wpgetapi->api_id ) {
        $url = add_query_arg( 'limit', 5, $url );
    }
    return $url;
}, 10, 2 );

Output — the request URL for the demo_api API becomes:

https://dummyjson.com/products?limit=5

The $wpgetapi adapter object#

Callbacks receive a plain object emulating WPGetAPI’s WpGetApi_Api instance (WPGetAPIBridge::build_adapter()):

Bridged filters — Post Creator + pagination (Pro)#

Source: src/Compat/WPGetAPIPostCreatorBridge.php (Pro, HOOK_MAP). Same wpgetapi_compat toggle; same validate-and-revert strategy via the free plugin’s shared validator and warning store.

Related native hooks: huxx_connect/post_creator/should_update, huxx_connect/post_creator/item_hash.

Unbridgeable hooks#

These WPGetAPI hooks cannot be bridged faithfully because they reach into parts of WPGetAPI’s architecture that HuxxConnect does not replicate (admin form rendering, runtime type inference, vertical-specific integrations). Snippets using them need the listed alternative.

Pagination type filters#

apply_filters( 'wpgetapi_pre_api_to_posts_pagination_type', null, $api_id, $endpoint_id );
apply_filters( 'wpgetapi_api_to_posts_pagination_type',     $type, $api_id, $endpoint_id );

Why: WPGetAPI infers pagination type at runtime by inspecting the response shape (keys like page, url, Pagination, maxPage) and lets these filters override that inference. HuxxConnect declares pagination type explicitly in the endpoint’s pagination config (cursor / page_number / offset) at config time — there is no runtime type to override.

Partial bridge via synthesis: when a migrated endpoint has no native pagination config, the toggle is on, wpgetapi_pre_api_to_posts_pagination_next_value (or the non-pre variant) has a subscriber, and a probe of both *_pagination_next_value filters — called with a null next value and empty payload for that specific api_id/endpoint_id — returns a non-null value, Post Creator synthesizes a minimal pagination config at runtime — applying both pagination-type filters at synthesis time to determine the query parameter name. A globally registered filter that guards on a different api_id returns null for the probe, so synthesis does not engage for that endpoint. Caveats:

• Synthesis only runs while no native pagination config exists; once pagination is configured on the endpoint, the native config wins and the filter is ignored.
• Type is hardcoded to page_number — custom cursor or offset flows must be configured natively.
• Only the parameter name is taken from the filter; the start value defaults to 1 and the items path to the Post Creator root path.

Alternative: configure pagination explicitly on the endpoint. For conditional behavior, hook huxx_connect/pagination/next_value to override the resolved next value (the bridge already routes both *_pagination_next_value filters to this native hook).

Field-mapping admin UI filters#

apply_filters( 'wpgetapi_post_import_before_field_mapping', $fields, $key, $item );
apply_filters( 'wpgetapi_post_import_after_field_mapping',  $fields, $key, $item );

Why: these fire inside WPGetAPI’s CMB2-rendered admin form, around each per-key mapping row, letting users inject additional CMB2 fields into the editor. HuxxConnect’s mapping UI is JavaScript-driven; there is no PHP filter point in the rendering loop where new admin fields could be injected.

Alternative: none today. If you use these to add admin-side UI controls, file a feature request describing the goal — concrete use cases guide whether an extension seam gets added.

Mapping sample-item picker#

apply_filters( 'wpgetapi_api_to_posts_get_item_for_mapping', $i );

Why: selects which item index in the API response is used as the sample for the mapping picker preview. HuxxConnect’s field discovery does not sample by index — it walks the response shape differently. Bridging would require both a new native hook and a UI seam in the mapping picker.

Alternative: none yet; a native hook is under consideration.

Array-to-JSON conversion toggle#

apply_filters( 'wpgetapi_api_to_posts_map_fields_array_value_convert_to_json', $bool, $map_key, $value, $api_id, $endpoint_id );

Why: WPGetAPI defaults to JSON-encoding array values when writing to plain post meta and lets users disable that per key. HuxxConnect’s storage adapters (ACF, Meta Box, plain post meta, taxonomy terms) handle array values natively per adapter type — there is no single “convert to JSON?” decision point because the correct shape depends on the adapter.

Alternative: choose the field adapter that matches the target storage shape (ACF for repeater/relationship fields, Meta Box for groups, plain meta for serialized arrays), or hook huxx_connect/post_creator/field_mapped to transform the value before write.

WooCommerce / EDD-specific hooks#

apply_filters( 'wpgetapi_wc_before_create_update_product',        $product, $args );
apply_filters( 'wpgetapi_api_to_posts_regular_price_before_save', ... );
apply_filters( 'wpgetapi_api_to_posts_sale_price_before_save',    ... );
apply_filters( 'wpgetapi_api_to_posts_wc_before_product_save',    $product, $args );
apply_filters( 'wpgetapi_edd_before_create_update_download',      $post );
apply_filters( 'wpgetapi_api_to_posts_edd_before_product_meta_save', ... );

Why: HuxxConnect does not ship WooCommerce or Easy Digital Downloads adapters. Post Creator targets generic custom post types and lets the user choose any post type; vertical-specific save paths are out of scope.

Alternative: hook the standard WooCommerce / EDD save actions (woocommerce_new_product, woocommerce_update_product, save_post_download, etc.) on top of HuxxConnect’s huxx_connect/post_creator/after_create / huxx_connect/post_creator/after_update actions. WC/EDD then handles its own product-type sidecars in its normal pipeline.

Admin sidebar HTML filter#

apply_filters( 'wpgetapi_admin_sidebar_display', $html );

Why: filters the HTML output of WPGetAPI’s admin sidebar. HuxxConnect’s admin chrome is entirely different, with no equivalent sidebar — there is nothing to filter into.

Alternative: none. This is purely WPGetAPI chrome.