Ana içeriğe geç

Export Import

bilgi

The renewed Export/Import Wizard lets you export an object (API Proxy, Proxy Group, global policy, policy group, etc.) together with everything it depends on in a single package, and when you import that package into another project or another Apinizer installation, map every dependency to its counterpart in the destination. The goal is to move a configuration to another project or environment without rebuilding it by hand or losing its references.

Supported Object Types​

The wizard groups the exportable/importable object types into four categories. The Dependencies column shows whether exporting that type involves an extra dependency step:

CategoryObject TypeDependencies
API ManagementAPI ProxyYes
API ManagementProxy GroupYes
API ManagementAPI Creator (DB to API / Script to API / Mock API)Yes
API ManagementPolicy GroupYes
Global SettingsGlobal PolicyYes
Global SettingsSettings GroupNo
Global SettingsEnvironment VariableNo
IdentityCertificate / Key Store / Crypto Key / JWKNo
IdentityIP GroupNo
IdentityCredentialYes
AILLM ProviderYes
AIProvider DefinitionNo
AIModel DefinitionYes
AIVector DBYes
AIKnowledge BaseYes
AIPII PresetNo
AIPrompt Guard PresetNo
bilgi

An MCP server or A2A agent is no longer a separate exportable object type. It travels inline — inside the MCP Call (LLM) / MCP Call (Fixed) (or A2A Call (LLM) / A2A Call (Fixed)) policy that embeds it, and inside a Passthrough MCP/A2A Gateway's own routing configuration — as part of the API Proxy package that contains it. A package from an older release that still carries a standalone MCP/A2A connection object is rejected on import with an explanatory error rather than silently skipped.

Usage Flow​

The flow adapts automatically to whether the object type you pick carries dependencies:

  • Types with dependencies (API Proxy, Proxy Group, API Creator, Global Policy, Policy Group, Credential, LLM Provider, Model Definition, Vector DB, Knowledge Base) go through the wizard's full steps: you select the object(s), the dependency tree is resolved, you choose which dependencies to include on export; on import, every dependency is mapped to its counterpart in the target project. If none of the selected objects turn out to have a resolvable dependency, the Dependencies step shows an explicit empty-state message instead of a blank list.
  • Types without dependencies (Settings Group, Environment Variable, the certificate family, IP Group, Provider Definition, PII Preset, Prompt Guard Preset) skip the extra dependency/mapping step — the object is exported directly as soon as it is selected, and on import the wizard moves straight from the file upload to the options step.
Choose Type

Choose the object type to export (API Proxy, Global Policy, Credential, etc.).

Export wizard type selection
Select Object(s)

The project's objects of that type are listed; you can select more than one at once.

Export wizard object selection
Dependencies (if any)

Every global policy, settings group, certificate, IP group, credential, environment/global variable, and API Creator connection used by the selected object(s) is scanned automatically. You can uncheck any dependency you don't want. An automatic advisory scan (certificate expiry, secret reminders, missing environment variables) is shown here too.

Export wizard Dependencies step
Review & Download

The package contents are summarized, you give it a file name, and it is downloaded as a ZIP.

Export wizard review and download

Under Package Encryption (optional) you can set a passphrase for the package: with a passphrase the whole package — the names of the objects inside it included — is encrypted, and leaving the field empty produces a plain package exactly as before. Once you type a passphrase, a Passphrase (confirm) field appears; until the two match, a passphrases do not match warning is shown and the download button stays disabled. The passphrase itself is never stored anywhere and cannot be recovered — losing it means the package can never be imported again.

Package Encryption​

Encryption is optional and off by default. A package exported without a passphrase is produced exactly as it was before and stays compatible with earlier Apinizer versions, so nothing changes for your existing export/import habits.

When you set a passphrase on the export wizard's last step, the entire package is encrypted. This protection covers not only the secret values inside the package but the names of the objects in it as well — someone who obtains the package cannot tell anything about its contents from the outside, not even which proxies, certificates or policies it carries.

The encryption key is derived directly from your passphrase. The passphrase itself is never written into the package and is not stored by Apinizer either; the only thing that can open the package is the same passphrase you typed on export.

uyarı

The passphrase cannot be recovered. Because Apinizer does not store it, there is no way to reset a forgotten or lost passphrase or to recover it from the package — the package can never be imported again.

Share the package and the passphrase over separate channels. Sending the package by e-mail and writing the passphrase into that same e-mail defeats the protection encryption gives you.

When to Use It​

Prefer encryption especially in these situations:

  • The package carries secret values such as a certificate's private key or a key store's password.
  • The package will travel over an unsecured channel such as e-mail, a file sharing service or a shared directory.

When the package stays in a secure environment and carries no secret values, you can continue without a passphrase.

Encryption over APIops​

The same encryption is available when you automate export/import over APIops; you can import a package produced by the wizard over APIops, or the other way round. For parameter and request-header details see the related API Reference pages: Export API Proxy, Import API Proxy, Export Key and Export Keystore.

Mapping & Dependencies​

Dependency detection and mapping are the most critical part of the wizard — how portable an object is depends on every resource it uses being resolved correctly in the destination.

Policy Group Dependency Detection & Mapping
  • When an API Proxy, Proxy Group, or Policy Group is exported, every policy inside it is scanned; each policy marked global (standalone or inside a policy group) is listed as its own dependency.
  • The global policies inside a Policy Group are added as separate dependencies in addition to the group itself — so both the group and the global policies inside it are created or mapped correctly in the destination. Local (non-global) child policies travel embedded with the group.
  • Every policy also surfaces the certificate, IP group, and credential it uses as its own dependencies (for example, the JWK used by a JOSE policy, or the IP group used by an IP rule policy).
  • When a Proxy Group is exported, each member API Proxy is resolved with its own full dependency tree, exactly as if it were exported on its own.
  • A dependency used by more than one selected object is shown only once, flagged as shared, and written into the package only once.
Global Policy / Environment Variable / Credential Key Mapping
  • When a Global Policy is mapped to an existing target policy on import, every API Proxy, Proxy Group, and Policy Group that references it is repointed to the target policy — so no duplicate is created from a name collision, and the same target policy keeps being used.
  • Environment variable dependencies are matched by name: every ${VARIABLE_NAME} reference in the package is rewritten to the name of the target variable you choose. If no variable of the same name exists in the target, you can create a Global or an Environment-specific variable from the packaged definition; creating an environment-specific one maps the source environment names to target environments. Variable values are never included in the package — they must be entered in the target separately.
  • Credential dependencies are matched by username; secrets such as passwords or keys never travel as plain text — they are either mapped to an existing credential or re-entered in the target. When a credential's certificate, key store, or trust store reference can't be resolved in the target, it is no longer left silently broken: the reference is cleared, and the import report carries a visible warning so you know to re-select the correct certificate there.
  • When a Certificate / Key Store / Crypto Key / JWK dependency is mapped, every file that references it (a credential's private key, the JWK used by a JOSE policy, a proxy's secure-connection certificates, etc.) is rewritten to point at the target's identity. Where a package does carry such secret material — for example when a certificate or a key store is exported on its own — exporting it with a passphrase is what keeps that material unreadable outside the target.
  • An environment id inside a package belongs to the source installation, so a certificate-family entry whose environment has no counterpart in the target is dropped on import rather than persisted. Where such a reference is still present on an object, the Certificate, Key Store, Crypto Key and JWK screens flag it with an Unknown environment warning instead of printing a raw identifier — the broken assignment stays visible and can be corrected from that same row. The API Manager's own apimanager environment is the one exception: it is a pseudo-environment that never exists as a row under Environments, is always treated as valid, and is shown under its own name.
  • When a database connection dependency is mapped, the API Creator's embedded connection reference is repointed to the target connection; connection passwords are never included in the package, and only connections of the same database type are offered as mapping candidates (for example, an Oracle connection can only be mapped to another Oracle connection).
Excluded Dependency Behavior
  • In a package with multiple objects (for example several API Proxies, or a Proxy Group's member proxies), you can remove an object you don't want from the import; only the dependencies used exclusively by that object are dropped with it — dependencies also used by an object you kept remain in the package.
  • If you uncheck a dependency on export, it is left out of the package entirely; the object that references it keeps carrying the source reference as-is, and if that dependency doesn't exist in the target, the reference has to be completed there manually.
  • Before export, an automatic advisory scan runs: certificates nearing expiry, secret environment variables, certificate/connection/credential secret reminders, and — on the import side — environment variables missing from the target project are all reported here. These reminders describe an unencrypted package; if you export with a passphrase, the values they warn about are encrypted along with the rest of the package.
Relative Path Rules on Project Import
  • On export, the source project's relative-path prefix is stripped from the API Proxy/Proxy Group's Client Route, leaving only the proxy-specific suffix in the package — so the package isn't tied to the source project.
  • On import, the target project's own relative-path prefix (when enabled) is prepended automatically; the Client Route editor shows this prefix as fixed (non-editable), and only the proxy-specific suffix can be edited — so the proxy comes online under the correct path in the new project without the prefix being duplicated.
AI Object Dependency Detection & Mapping
  • An LLM Provider's dependency step surfaces the provider type definition it points at, but only when that definition is a custom one your project created; a built-in definition Apinizer ships (OpenAI, Anthropic, Azure, Bedrock, etc.) never travels in the package — on import it is re-linked automatically from the provider's own identifying code, so there is nothing to map for it. The same step also surfaces any custom model catalog entries defined under that provider — these travel in the package as dependencies and are created automatically in the target on import; built-in catalog models aren't included, since the target installation already recognizes them out of the box. The LLM Provider itself always carries its own secret (its API key/secret), so it is always packaged as a secret dependency.
  • A Knowledge Base surfaces the Vector DB connection and the embedding LLM Provider it was built on. Only the knowledge base's own definition travels in the package — the documents already indexed into it are not part of it and have to be (re-)ingested in the target.
  • MCP/A2A gateway proxies are exported as API Proxies (type=MCP / type=A2A) with no separate connection dependency to resolve: a Passthrough proxy's backend server(s) and a Tool Call / Agent Call policy's embedded server are packaged inline, as part of the proxy itself.
  • Model Definition and Vector DB also go through the dependency step: a custom model definition can reference a custom provider definition, and a Vector DB connection's settings can contain environment variable references — both are resolved and mapped the same way as any other dependency. When neither applies to the selection, the step shows the same empty-state message described above. PII Preset and Prompt Guard Preset carry no reference to another exportable object — each is a self-contained pattern definition — so both are exported directly, without a separate dependency step. A Provider Definition is likewise self-contained (it only carries its own default endpoint and auth settings) and is exported directly as well.
  • PII Preset and Prompt Guard Preset — including the ones scoped to your own project — can only be created or edited by a system administrator. From a regular project, the wizard's object list only shows presets already made available to your project; the platform's built-in preset catalog does not appear there.

Usage Scenarios​

Transfer Between Environments​

Assume that there are two Apinizer applications installed in two different environments named production and test due to access restrictions. The production environment serves clients, while the test environment serves software developers. It is desired that API Proxies and applied policies and configurations in the test environment also be applied to the production environment. In this case, the API Proxy in the test environment is exported together with its dependencies. The resulting package is then imported into the production environment through the wizard, and each dependency is mapped to its counterpart there.

Configuration Tracking​

Configuration changes can be tracked. The organization may want to track differences in policy settings due to security rules. For this, the exported policy, API Proxy, or project configuration file should be added to the CI process.

En son tarihinde güncellendi