HuxxConnect reads WPGetAPI’s configuration directly from your database and converts it in place — no export file needed. This page covers the one-click migrator; for the decision between migrating, bridging old code, or both, see WPGetAPI: Migration Paths.
Quick version:
- Keep WPGetAPI active (its encryption class is needed to decrypt stored parameter values).
- Go to HuxxConnect → Import / Export. A “Migrate from WPGetAPI” card appears when WPGetAPI configuration is detected.
- Click Preview to see what will be created or updated.
- Pick a Migration Mode — Merge (update existing, add new) or Add New Only (skip existing) — and click Migrate Now.
- Test each migrated endpoint, then deactivate WPGetAPI.
Before you run it
Leave the WPGetAPI plugin active during migration. WPGetAPI encrypts parameter values (AES-256-CTR keyed from your site’s auth constants), and the migrator uses WPGetAPI’s own encryption class to decrypt them. If WPGetAPI is deactivated, migration still runs — the detection works from the stored options alone — but any encrypted values are copied as-is and will not work.
New to APIs? Read this first
Migration only copies configuration — which URLs to call, with which credentials and parameters. It doesn’t touch your posts or pages. You can run it, compare results side by side, and deactivate WPGetAPI only when you’re satisfied.
Take a database backup first if the site matters. Migration writes new HuxxConnect records and never modifies WPGetAPI’s data, but a backup makes any experiment reversible.
Run the migrator
- Go to HuxxConnect → Import / Export. If WPGetAPI configuration exists in the database (even with the plugin deactivated), the page opens with a Migrate from WPGetAPI card: “WPGetAPI configuration detected. You can migrate your existing APIs and endpoints to HuxxConnect.”
Click Preview. A “Found:” list shows each API and endpoint with the action the migrator will take (create or update), based on the selected mode.
Choose a Migration Mode:
- Merge (update existing, add new) — default. Existing HuxxConnect items with matching IDs are updated; everything else is added. Safe to re-run.
- Add New Only (skip existing) — never touches an existing HuxxConnect API or endpoint.
Click Migrate Now. When it finishes, the migration is recorded (via the
huxx_connect_wpgetapi_migratedoption); the card itself remains visible as long as WPGetAPI data exists in the database.
If HuxxConnect Pro is active, two sibling migrations run in the same flow: WPGetAPI OAuth add-on credentials (tokens and your provider-registered callback URL are preserved — see Set up OAuth2) and WPGetAPI API to Posts importer configurations into Pro’s Post Creator (see Map API fields to posts). Without Pro, free migration covers APIs and endpoints, and the card tells you OAuth credentials were detected but need Pro.
What maps to what
Verified against src/Migration/WpGetApiMigrator.php:
| WPGetAPI | HuxxConnect | Notes |
|---|---|---|
| API name, ID, base URL | API name, ID, base URL | Base URL is URL-decoded and trailing slash trimmed. IDs are normalized: lowercase, hyphens become underscores (my-api → my_api). |
| Endpoint ID, path, method | Endpoint ID, path, HTTP method | A display name is generated from the ID (get_users → “Get Users”). If a ?foo=bar suffix was pasted into the path, it is peeled off into structured query parameters. |
| Query / header / body parameters | Query / header / body parameters | Name/value pairs become key/value pairs; encrypted values are decrypted (WPGetAPI must be active). |
| Auth headers on endpoints | API-level authentication | When every endpoint that carries an Authorization: Bearer … header uses the same token, it is promoted to API-level Bearer token auth (endpoints without the header inherit it); the same rule promotes an identical X-API-Key / Api-Key / ApiKey header value to API key auth. The promoted header is removed from each endpoint. Mismatched values, and anything else, stay plain headers with auth type “none”. |
body_json_encode | Body encoding + body format | true → JSON, url → URL-encoded, false/base64/xml → raw. A single empty-name body param containing JSON becomes nested JSON storage; nested values in JSON-encoded bodies also promote to the JSON editor. See Choose a body format. |
results_format | Results format | json_decoded, json_string, and xml_array carry over directly. |
cache_time | Cache duration | Per endpoint. See Cache endpoint responses. |
| Timeout, SSL verify | Timeout, SSL verify | Timeout at API level plus per-endpoint override; SSL verification at API level. |
The ID normalization matters for old code: wpgetapi_endpoint( 'my-api', … ) with a hyphen still resolves after migration because the compatibility bridge applies the same normalization at call time.
Post-migration checklist
- Test every migrated endpoint. Open each API in HuxxConnect → APIs and send a test request; see Debug API requests for reading the results.
- Review detected authentication. Confirm the promoted Bearer token or API key is correct, and set auth up manually for anything the detector left as “none” — see Understanding authentication.
- Pick an encryption tier for the migrated credentials: Choose an encryption tier.
- Bridge or rewrite custom code. If theme or snippet code calls
wpgetapi_*, either enable the bridge (Keep existing WPGetAPI code working) or port toHuxxConnect: "api_id" attribute is required./huxx_api()(Shortcodes, Template functions). - Deactivate WPGetAPI once everything checks out. Its stored options are left untouched, so you can always roll back.
If it didn’t work
The “Migrate from WPGetAPI” card doesn’t appear. The card only renders when the wpgetapi_setup option exists in the database with at least one API. If WPGetAPI was configured on a different site (or a different network site in multisite), there is nothing to detect on this one. Use WPGetAPI’s own export file with the importer instead — note WPGetAPI exports contain endpoints only, so you’ll select an existing API to import them into.
Migration fails with “No WPGetAPI configuration found.” Same root cause as above, hit at run time: the wpgetapi_setup option is missing or has an empty API list.
Requests fail after migration with authentication errors. Most likely the migration ran while WPGetAPI was deactivated, so encrypted parameter values (tokens, keys) were copied in their encrypted form. Reactivate WPGetAPI, re-run the migration in Merge mode, and re-test.