After migrating your data, any custom code written against WPGetAPI — filter snippets, wpgetapi_endpoint() calls in templates, [wpgetapi_endpoint] shortcodes in content — would otherwise go dead. The compatibility bridge routes all of it through HuxxConnect. This page covers enabling it, verifying it, and the rules for running alongside WPGetAPI. Hook-by-hook details live in the WPGetAPI Compatibility Reference.
Quick version:
- HuxxConnect → Settings → turn on the WPGetAPI Compatibility toggle.
- That single toggle activates all three surfaces: the bridged
wpgetapi_*filters, thewpgetapi_endpoint()function, and the[wpgetapi_endpoint]/[wpgetapi]shortcode aliases (shortcodes only while WPGetAPI itself is inactive).- Exercise your old code, then check the warnings panel under the toggle. “No compatibility warnings recorded in the last 24 hours.” means clean.
- Bridged calls log a migration hint naming the native replacement — retire call sites at your own pace.
Enable the bridge
Go to HuxxConnect → Settings and switch on WPGetAPI Compatibility. The setting’s help text states the scope: “If you have custom code using wpgetapi_* filters, the wpgetapi_endpoint() function, or [wpgetapi_endpoint] shortcodes, enable this to route those calls through HuxxConnect. Incompatible filter changes will be safely reverted and logged.”
The bridge is off by default. While it is off, wpgetapi_endpoint() returns false (it is still defined, so nothing fatals), the shortcode aliases are not registered, and wpgetapi_* filters never fire. HuxxConnect also watches for that misconfiguration: if the bridge is off but callbacks are registered on bridged wpgetapi_* hooks, an admin notice — “HuxxConnect: WPGetAPI filter code detected” — lists the hooks and links to Settings.
What is bridged
One toggle controls three surfaces (source: src/Compat/WPGetAPIBridge.php, src/Compat/WPGetAPIFunctions.php, src/Compat/WPGetAPIFunctionCompat.php):
wpgetapi_endpoint( $api_id, $endpoint_id, $args )— executes through HuxxConnect and returns the response data. Runtime argsdebug,endpoint_variables,query_variables,body_variables,header_variables, andresults_formatpass through; WPGetAPI’skeysextraction syntax is translated to native keys syntax;format=no_displayexecutes and returns an empty string. HTML/number formatting args apply only via the shortcode, and only with HuxxConnect Pro active (Pro) — the function always returns raw data and logs a warning if formatting args are passed, and without Pro the shortcode returns raw data too.- Shortcode aliases
[wpgetapi_endpoint]and[wpgetapi]— attributes are remapped (IDs normalized,keystranslated) and rendering delegates to the nativeHuxxConnect: "api_id" attribute is required.renderer. - Ten request/response lifecycle filters —
wpgetapi_endpoint,wpgetapi_query_parameters,wpgetapi_header_parameters,wpgetapi_body_parameters,wpgetapi_default_request_args_parameters,wpgetapi_final_url,wpgetapi_final_request_args,wpgetapi_should_we_stop,wpgetapi_before_retrieve_body,wpgetapi_raw_data. Your callbacks receive an adapter object emulating the$wpgetapiinstance (->api_id,->query_parameters,->args, and so on). With HuxxConnect Pro, seven WPGetAPI “API to Posts” filters are additionally bridged into Post Creator and pagination — see the reference.
Every filter return is validated. A structurally invalid return (wrong type for the hook) is reverted to the original value and logged, so one bad snippet cannot corrupt outgoing requests.
Slug normalization is automatic: WPGetAPI IDs with hyphens map to their migrated underscore form at call time, so wpgetapi_endpoint( 'my-api', 'get-users' ) finds the migrated my_api / get_users.
Verify it
- Load a page (front-end or admin) that exercises your old shortcodes, function calls, or filters, and confirm the output matches what WPGetAPI produced.
- Return to Settings → WPGetAPI Compatibility. The panel under the toggle either shows “No compatibility warnings recorded in the last 24 hours.” or a table of warnings.
- Expect informational entries for each legacy call: the bridge logs one hint per surface (function/shortcode) per API/endpoint pair per request, naming the native replacement (for example
huxx_api('my_api', 'get_users')or). These are migration breadcrumbs, not errors. - Investigate reverted warnings — they mean a filter returned an invalid value and the bridge discarded the change. Fix the snippet or port it to the native hook (for example huxx_connect/request/args).
Coexistence rules
The bridge is designed to never fight WPGetAPI for the same surface:
- Functions: HuxxConnect only defines
wpgetapi_endpoint()/wpgetapi_api_to_posts()when WPGetAPI hasn’t already defined them (and skips defining them while a WPGetAPI activation request is in flight, since WPGetAPI doesn’t guard its own definitions). If WPGetAPI is active, its functions win. - Shortcodes: the
[wpgetapi_endpoint]/[wpgetapi]aliases register only when WPGetAPI’s classes are absent. While both plugins are active, WPGetAPI keeps rendering its own shortcodes. - Filters: bridged
wpgetapi_*filters fire from HuxxConnect’s request pipeline. Requests still made by WPGetAPI itself are untouched — during a side-by-side transition period, each plugin runs its own calls. wpgetapi_api_to_posts()is a stub: it returns an empty array and logs a warning, because WPGetAPI’s API-to-Posts function API has no HuxxConnect equivalent. Recurring content sync is Pro’s Post Creator — see Map API fields to posts (Pro).
The practical sequence: migrate data → enable the bridge → verify → deactivate WPGetAPI (the aliases and function stubs take over on the next load) → port call sites to native syntax over time → switch the toggle off.
If it didn’t work
wpgetapi_endpoint() returns false everywhere. That is the stub’s off-state. Confirm the WPGetAPI Compatibility toggle is on.
Fatal error: call to undefined function wpgetapi_endpoint(). The call runs before plugins_loaded — the stub file loads at HuxxConnect boot, so calls made earlier hit an undefined function. Move the call to plugins_loaded or later.
A filter’s changes don’t take effect. Check the warnings table in Settings. If the return was reverted, your callback returned an invalid shape for that hook — common after the switch because the adapter, while close, is not a real WpGetApi_Api instance. Also verify your ID checks: compare against the migrated underscore form (my_api), or use the adapter’s ->api_id, which is already normalized.
The shortcode renders nothing. If WPGetAPI is still active, it owns [wpgetapi_endpoint] and renders against its own (old) configuration — deactivate it to hand the shortcode to HuxxConnect. If WPGetAPI is inactive, confirm the API and endpoint IDs resolve after normalization (hyphens become underscores) and that the endpoint works from the HuxxConnect admin — see Debug API requests.