---
title: "WPGetAPI: Migration Paths"
slug: wpgetapi-migration-paths
type: explanation
plugin: huxx-connect
summary: How to choose between the WPGetAPI compatibility bridge, a full data migration, or both — and where the bridge's limits are.
keywords: [wpgetapi, migration, compatibility bridge, decision guide]
version_added: 1.2.5
version_updated: 1.2.5
level: intermediate
related: [migrate-from-wpgetapi, keep-wpgetapi-code-working, wpgetapi-compatibility]
---

Moving from WPGetAPI to HuxxConnect is like moving to a new house. The **migrator** is the moving truck: it carries your belongings — APIs, [endpoints](/docs/connect/explanation/glossary/#endpoint), parameters, [credentials](/docs/connect/explanation/glossary/#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() /
      │               [huxx_api] / 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](/docs/connect/explanation/glossary/#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()`, `[huxx_api]` instead of `[wpgetapi_endpoint]`, and `huxx_connect/request/*` filters (see [huxx_connect/request/args](/docs/connect/reference/filter-hooks/#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).

:::novice
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](/docs/connect/explanation/how-huxxconnect-works/).
:::

## What the bridge can do

The bridge covers three surfaces (full details in the [WPGetAPI Compatibility Reference](/docs/connect/reference/wpgetapi-compatibility/)):

- **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](/docs/connect/reference/wpgetapi-compatibility/); the categories are:

| Gap | Why it can't be bridged | What 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 hooks | HuxxConnect 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

- [Migrate from WPGetAPI](/docs/connect/how-to/migrate-from-wpgetapi/) — run the migrator and verify the result.
- [Keep existing WPGetAPI code working](/docs/connect/how-to/keep-wpgetapi-code-working/) — enable and verify the compatibility bridge.
- [WPGetAPI Compatibility Reference](/docs/connect/reference/wpgetapi-compatibility/) — every bridged hook, signature, and the complete unbridgeable list.