---
title: "Keep Existing WPGetAPI Code Working"
slug: keep-wpgetapi-code-working
type: how-to
plugin: huxx-connect
summary: Enable the WPGetAPI compatibility bridge so existing wpgetapi_* filters, function calls, and shortcodes keep running through HuxxConnect.
keywords: [wpgetapi, compatibility bridge, filters, shortcodes]
version_added: 1.2.5
version_updated: 1.2.5
level: advanced
related: [wpgetapi-migration-paths, migrate-from-wpgetapi, wpgetapi-compatibility]
---

After [migrating your data](/docs/connect/how-to/migrate-from-wpgetapi/), 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](/docs/connect/explanation/glossary/#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](/docs/connect/reference/wpgetapi-compatibility/).

> **Quick version:**
> 1. **HuxxConnect → Settings** → turn on the **WPGetAPI Compatibility** toggle.
> 2. That single toggle activates all three surfaces: the bridged `wpgetapi_*` filters, the `wpgetapi_endpoint()` function, and the `[wpgetapi_endpoint]` / `[wpgetapi]` shortcode aliases (shortcodes only while WPGetAPI itself is inactive).
> 3. Exercise your old code, then check the warnings panel under the toggle. "No compatibility warnings recorded in the last 24 hours." means clean.
> 4. 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."

<!-- screenshot-todo: settings--wpgetapi-compat-enabled--toggle-and-warnings-panel | alt: Settings page with the WPGetAPI Compatibility toggle on and the warnings panel reporting no warnings in 24 hours -->

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 args `debug`, `endpoint_variables`, `query_variables`, `body_variables`, `header_variables`, and `results_format` pass through; WPGetAPI's `keys` extraction syntax is translated to native [keys syntax](/docs/connect/reference/keys-syntax/); `format=no_display` executes 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, `keys` translated) and rendering delegates to the native `[huxx_api]` 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 `$wpgetapi` instance (`->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](/docs/connect/reference/wpgetapi-compatibility/).

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

1. Load a page (front-end or admin) that exercises your old shortcodes, function calls, or filters, and confirm the output matches what WPGetAPI produced.
2. 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.
3. 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 `[huxx_api api="my_api" endpoint="get_users"]`). These are migration breadcrumbs, not errors.
4. 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](/docs/connect/reference/filter-hooks/#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](/docs/connect/how-to/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](/docs/connect/how-to/debug-api-requests/).