--- title: "Migrate from WPGetAPI" slug: migrate-from-wpgetapi type: how-to plugin: huxx-connect summary: Run the built-in migrator to convert WPGetAPI APIs, endpoints, parameters, and detected auth into HuxxConnect, then verify the result. keywords: [wpgetapi, migration, migrator, import] version_added: 1.2.5 version_updated: 1.2.5 level: intermediate related: [wpgetapi-migration-paths, keep-wpgetapi-code-working, wpgetapi-compatibility, import-and-export-configurations] --- 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](/docs/connect/explanation/wpgetapi-migration-paths/). > **Quick version:** > 1. Keep WPGetAPI **active** (its encryption class is needed to decrypt stored parameter values). > 2. Go to **HuxxConnect → Import / Export**. A "Migrate from WPGetAPI" card appears when WPGetAPI configuration is detected. > 3. Click **Preview** to see what will be created or updated. > 4. Pick a **Migration Mode** — *Merge (update existing, add new)* or *Add New Only (skip existing)* — and click **Migrate Now**. > 5. 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. :::novice Migration only copies configuration — which URLs to call, with which [credentials](/docs/connect/explanation/glossary/#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 1. 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." 2. 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. 3. 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. 4. Click **Migrate Now**. When it finishes, the migration is recorded (via the `huxx_connect_wpgetapi_migrated` option); 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](/docs/connect/how-to/set-up-oauth2/)) and WPGetAPI **API to Posts** importer configurations into Pro's Post Creator (see [Map API fields to posts](/docs/connect/how-to/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](/docs/connect/how-to/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](/docs/connect/how-to/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](/docs/connect/explanation/glossary/#compatibility-bridge) applies the same normalization at call time. ## Post-migration checklist 1. **Test every migrated endpoint.** Open each API in **HuxxConnect → APIs** and send a test request; see [Debug API requests](/docs/connect/how-to/debug-api-requests/) for reading the results. 2. **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](/docs/connect/explanation/understanding-authentication/). 3. **Pick an encryption tier** for the migrated credentials: [Choose an encryption tier](/docs/connect/how-to/choose-an-encryption-tier/). 4. **Bridge or rewrite custom code.** If theme or snippet code calls `wpgetapi_*`, either enable the bridge ([Keep existing WPGetAPI code working](/docs/connect/how-to/keep-wpgetapi-code-working/)) or port to `[huxx_api]` / `huxx_api()` ([Shortcodes](/docs/connect/reference/shortcodes/), [Template functions](/docs/connect/reference/template-functions/)). 5. **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](/docs/connect/how-to/import-and-export-configurations/) 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.