Skip to Main
View .mdAsk ClaudeAsk ChatGPT

Moving from WPGetAPI to HuxxConnect is like moving to a new house. The migrator is the moving truck: it carries your belongings — APIs, endpoints, parameters, credentials — into the new place in one trip. The compatibility bridge is mail forwarding: code that still writes to your old address (wpgetapi_* filters, the wpgetapi_endpoint() function, the [wpgetapi_endpoint] shortcode) keeps getting delivered, routed to the new house behind the scenes.

You can use either one alone, but most sites want both: move the furniture once, and keep the mail forwarding on until every correspondent has your new address.

The three paths

Do you have WPGetAPI APIs/endpoints configured?
│
├─ No ──────────────► Nothing to migrate. Enable the bridge only if
│                     theme/plugin code calls wpgetapi_* directly.
│
└─ Yes
   │
   Does custom code (theme, snippets, other plugins)
   call wpgetapi_endpoint(), [wpgetapi_endpoint], or
   add_filter('wpgetapi_...')?
   │
   ├─ No ───────────► PATH 1: Migrate only.
   │                  Run the migrator, verify, deactivate WPGetAPI.
   │
   └─ Yes
      │
      Can you update that code now?
      │
      ├─ Yes ───────► PATH 2: Migrate, then rewrite.
      │               Migrate data, port code to huxx_api() /
      │               HuxxConnect: "api_id" attribute is required. / huxx_connect/* hooks, skip the bridge.
      │
      └─ No ────────► PATH 3: Migrate + bridge (most common).
                      Migrate data, enable the bridge, rewrite
                      code at your own pace.

Path 1: Migrate only

Your WPGetAPI setup lives entirely in its admin screens — no code snippets touch it. Run the migrator from HuxxConnect → Import / Export, verify the migrated endpoints, and deactivate WPGetAPI. The bridge stays off; there is nothing for it to forward.

Path 2: Migrate, then rewrite

You have custom code, and you are ready to update it. Migrate the data, then port each call site to the native equivalents: huxx_api() instead of wpgetapi_endpoint(), HuxxConnect: "api_id" attribute is required. instead of [wpgetapi_endpoint], and huxx_connect/request/* filters (see huxx_connect/request/args) instead of wpgetapi_* filters. Native hooks receive HuxxConnect’s Api and Endpoint objects directly, with no adapter in between — the better long-term footing.

Path 3: Migrate + bridge

You have custom code you can’t rewrite today — a client’s theme, a snippet plugin full of filters, a third-party add-on. Migrate the data, then turn on the WPGetAPI Compatibility toggle in HuxxConnect → Settings. The bridge routes the old function, shortcodes, and filters through HuxxConnect’s pipeline, and logs a migration hint for each legacy function or shortcode call site so you can retire them over time (bridged filters log warnings only when an invalid return is reverted).

New to APIs? Read this first

A filter is a WordPress mechanism that lets one plugin modify another plugin’s data in flight. Sites often accumulate small filter snippets over the years — the bridge exists so those snippets keep working. See How HuxxConnect works.

What the bridge can do

The bridge covers three surfaces (full details in the WPGetAPI Compatibility Reference):

  • The wpgetapi_endpoint() function — defined by HuxxConnect whenever WPGetAPI hasn’t defined it, routed through HuxxConnect’s executor, including WPGetAPI’s keys extraction syntax.
  • Shortcode aliases — [wpgetapi_endpoint] and [wpgetapi] render through HuxxConnect’s native shortcode renderer (only registered while WPGetAPI itself is inactive).
  • Request/response lifecycle filters — ten wpgetapi_* filters (wpgetapi_final_url, wpgetapi_query_parameters, wpgetapi_raw_data, and others) are forwarded from the matching HuxxConnect hooks, with an adapter object that emulates the $wpgetapi instance your callbacks expect. With HuxxConnect Pro active, seven WPGetAPI “API to Posts” filters (item filtering, mapped values, pagination next-value and delay) are bridged into Pro’s Post Creator as well.

The bridge validates every filter return. If a callback returns something structurally invalid for that hook, the bridge reverts to the original value and records a warning in Settings → WPGetAPI Compatibility instead of sending a broken request.

What the bridge cannot do

Some WPGetAPI hooks reach into architecture HuxxConnect deliberately does not replicate. These are cataloged exhaustively in the reference; the categories are:

GapWhy it can’t be bridgedWhat to do instead
Pagination type filters (wpgetapi_*_pagination_type)WPGetAPI infers pagination type at runtime from the response shape; HuxxConnect declares it explicitly in the endpoint’s pagination config, so there is no runtime inference to override. A narrow synthesis path exists for code-only page-number pagination.Configure pagination on the endpoint; hook huxx_connect/pagination/next_value for conditional behavior.
Field-mapping admin UI filters (wpgetapi_post_import_before/after_field_mapping)These inject CMB2 fields into WPGetAPI’s PHP-rendered mapping form. HuxxConnect’s mapping UI is JavaScript-driven — there is no PHP render loop to inject into.No equivalent today; file a feature request with your use case.
Mapping sample-item picker (wpgetapi_api_to_posts_get_item_for_mapping)HuxxConnect’s field discovery walks the response shape rather than sampling by index.None yet; a native hook is under consideration.
Array-to-JSON conversion toggle (..._array_value_convert_to_json)HuxxConnect’s storage adapters (ACF, Meta Box, plain meta, taxonomy) each handle arrays natively — there is no single convert-to-JSON decision point.Pick the matching field adapter, or transform values via huxx_connect/post_creator/field_mapped.
WooCommerce / EDD product hooksHuxxConnect ships no WooCommerce or Easy Digital Downloads adapters; Post Creator targets generic post types.Hook standard WC/EDD save filters on top of huxx_connect/post_creator/after_create / after_update.
Admin sidebar HTML filter (wpgetapi_admin_sidebar_display)Pure WPGetAPI admin chrome; HuxxConnect has no equivalent sidebar.None — nothing to filter into.

If your snippets only touch the request/response lifecycle — by far the common case — the bridge covers you. If they lean on the gaps above, plan for Path 2 on those call sites.

See it in practice