Ana içeriğe geç

Export Import

Info

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 seven 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
API ManagementTest CollectionYes
Global SettingsGlobal PolicyYes
Global SettingsSettings GroupYes
Global SettingsEnvironment VariableNo
Global SettingsGlobal VariableNo
IdentityCertificate / Key Store / Crypto Key / JWKNo
IdentityIP GroupNo
IdentityCredentialYes
IdentityConsumer RoleNo
IdentityIdentity Service (LDAP / Database / API / OIDC Provider)Yes
IdentityRegistered OrganizationNo
IdentityLimit PlanNo
IdentityAPI ClientYes
IdentityLimit AssignmentYes
IdentityAccess EntitlementYes
ConnectionsConnectionYes
Monitoring & ReportingTask FlowYes
Monitoring & ReportingUptime MonitorYes
Monitoring & ReportingAnomaly DetectorYes
Monitoring & ReportingCustom QueryYes
Monitoring & ReportingCustom Query FilterYes
Monitoring & ReportingReport ConfigurationYes
AILLM ProviderYes
AIProvider DefinitionNo
AIModel DefinitionYes
AIVector DBYes
AIKnowledge BaseYes
AIPII PresetNo
AIPrompt Guard PresetNo
AIDLP PresetNo
AIPrompt TemplateNo
AIPrompt DecoratorNo
AITopic CategoryNo
AdminSIEM SettingsYes
AdminAPI ProductYes
Info

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.

Reaching It from the Menu​

The entity-level Export/Import wizard is reachable from two places: the Export/Import group in the project menu, and the Administration → Export/Import group. The Administration group also holds the two whole-project pages:

  • Export Project — exports an entire project as a single ZIP. The page lets you pick the project explicitly from a permission-filtered list (only projects where you hold PROJECT_MANAGEMENT / EXPORT_IMPORT); the active project, if any, is only pre-selected, and Export stays disabled until a project is chosen. The entry therefore does not need an active project, and the menu and the page require the same PROJECT_MANAGEMENT / EXPORT_IMPORT permission (system administrators always pass). If you hold the permission in no project, the page shows an explanatory empty state instead of the list.
  • Import Project — imports a whole-project package and creates a new project from it. Because it creates the project, it needs no active project and is visible to system administrators only. The same page is also reachable from the button on the Administration → Projects screen.

The whole-project package is not part of the entity wizard's type catalog. That is a deliberate scope split: a project package carries different semantics — creating a new project, inspecting the package, choosing relative paths.

The Connection Object Type in the Wizard​

Connection is a main object type of its own, under the wizard's Connections category. It covers: Database Pool, Kafka, Elasticsearch, Mail, FTP, Graylog, Syslog, RabbitMQ, ActiveMQ, Webhook, Logback, SNMP, LDAP Pool and Linux Script — on all 14 of those list screens, the row menu's primary Export action and the toolbar Import button now open this wizard type directly, with the connection preselected (project scope, or Admin scope when opened from Administration). See Import Advisories Outside the Wizard below for the one exception.

  • Certificate dependencies travel with it: Kafka's and Syslog's key store and trust store, Webhook's key store and trust store, an LDAP Pool's certificate, and a Mail connection's certificate all surface automatically on this type's dependency step and can be packaged along — resolved the same way as any other certificate dependency described in Mapping & Dependencies above. A ${VARIABLE} reference in a connection's host, URL or password field travels the same way, as an environment or global variable dependency.
  • OTLP is outside this type: an OpenTelemetry (OTLP) connection is not part of this catalog and keeps its own separate path — it still exports and imports through the Import dialog on its own admin screen.
  • How it differs from the list screen's "Export as File" button: on these 14 screens, the row menu's secondary Export as File item (the raw single-file ZIP capability, kept from before this type existed) carries no dependencies — it exports only the connection's own fields, without a certificate or key store. When you need the certificate to travel together with the connection (for example an LDAP Pool secured with mTLS), the row menu's now-primary Export action — this wizard type — already does that by default.

It's reachable the same way as every other type — the project menu's Export/Import group and Administration → Export/Import — gated by the Connections permission category.

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, Settings Group, Test Collection, Credential, Identity Service, Connection, LLM Provider, Model Definition, Vector DB, Knowledge Base, API Client, Limit Assignment, Access Entitlement, Task Flow, Uptime Monitor, Anomaly Detector, Custom Query, Custom Query Filter, Report Configuration, SIEM Settings, API Product) 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 (Environment Variable, Global Variable, the certificate family, IP Group, Consumer Role, Registered Organization, Limit Plan, Provider Definition, PII Preset, Prompt Guard Preset, DLP Preset, Prompt Template, Prompt Decorator, Topic Category) 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.

Warning

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.

Package Integrity​

Every package Apinizer exports carries a record of its own contents: an extra file named apinizer-transfer-manifest.json that lists which files are in the package, what each of them is, and a fingerprint of each one. On import, Apinizer recalculates those fingerprints and compares them with the record before anything is written to the destination.

  • A package that arrives exactly as Apinizer produced it imports as it always did — you will not notice the check.
  • A finding that shows the package changed after export no longer ends the import on its own; a single acknowledgment carries it through. Three situations fall under that acknowledgment: a file inside the package whose content changed (its fingerprint no longer matches the record); a file added to or removed from the package; and an integrity record that cannot be read at all, or that disagrees with the files actually in the package. The decision is yours in all three: acknowledge it and the import continues with the package exactly as it arrived, decline and the import stops there with nothing at all written. When you acknowledge a record that cannot be read, the package is imported as if it carried no record.
  • How the acknowledgment is asked for depends on the screen. The wizard opens no separate window: the difference appears as a warning line on the step and the import continues. The single-file Import dialogs outside the wizard — the one on a connection's list screen and the policy Import dialog of an API Proxy or API Proxy Group (which imports a policy package as a local policy) — show a confirmation window titled Package Content Has Changed; confirming it opens the package again with the difference accepted. Those dialogs also ask for the passphrase of an encrypted package the same way, with an inline field after the first attempt. Administration → Projects → Import Project shows the same confirmation window; there the package is checked before the project is created, so a package you do not acknowledge leaves no empty project behind.
  • An acknowledged import stays traceable: when it finishes you see a warning telling you how many files disagreed with the record, and the acknowledging user — together with which package was acknowledged and when — is written to the operational log. That entry does not appear on the Audit Logs screen; it lives in the operational log only.
  • A package with no integrity record at all is not blocked. Packages produced by earlier Apinizer versions carry none and keep importing exactly as before; the wizard, the Import dialog on a connection's list screen and the Import Project screen show a "this package carries no integrity record" warning in that case. The policy Import dialog does not show this warning; there the package is imported silently.
  • What still cannot be acknowledged is about compatibility, not about the package having changed: a package carrying an integrity record format this installation does not know, one declaring a critical feature it does not recognise, or one produced with an unsupported fingerprint method is refused with a clear message instead of being read halfway. And if a file inside the package cannot be read at all — a text editor replaced its quotes with smart quotes, for example — it genuinely cannot be parsed, so that is not acknowledgeable either.
Info

This acknowledgment records that you continued knowing the package changed after export; it says nothing about who produced it. After acknowledging, review the imported objects: the difference was not produced by Apinizer.

Tip

Package files opened and saved again by a Windows text editor — the invisible marker such editors add at the start of a file, and the change of line endings — no longer break the import. Once the difference is acknowledged, the import runs through to the end.

Warning

If your process relies on unzipping an export file, editing a file inside it and re-compressing it, that package will no longer import automatically — you'll need to give the acknowledgment above to complete the import. Make the change in the source installation and export again, then use the file Apinizer produced as-is.

Re-packing a package without touching its contents still works — the check looks at each file's own content, not at how the archive was built. Prefer the original file anyway: some tools alter the files while re-compressing them.

Over APIops, see Import Objects for the acknowledgeChecksumMismatch parameter — which accepts all three situations above — and the advisory the response carries back when it was used.

Objects That Could Not Be Exported​

If an object cannot be written into the package while it is being produced, the export still completes for everything else — but the name of the missing object is now recorded inside the package's content record instead of disappearing without a trace. If a package turns out to be missing something you selected, open the record file inside it: the objects that did not make it are listed there by name.

Packages That Carry Secret Material​

Some object types travel with their secret values readable inside the package — an AI provider's API key, a key store's password, or a certificate's private key, for example. An Uptime Monitor's, Anomaly Detector's, Task Flow Manager's or Report Generator's package carries one more such value: when a notification connector inside it has its own privacy setting turned on, the salt behind that connector's masking/hashing rules travels in the package as plain text too — the same way a SIEM destination's privacy salt does (see SIEM Settings below). When such an object is included, the export wizard now warns you before you download the file and names the objects concerned; the warning never shows the values themselves.

Treat such a file as you would the secrets in it, and where it has to leave a trusted environment, export it with a passphrase — see Package Encryption above.

Very Old Packages Can No Longer Be Imported​

Types such as an LLM Provider, a Vector DB and an OpenTelemetry (OTLP) connection write their secret values into the package in readable form, and the import encrypts them again on the destination. Much older packages, produced before that behaviour, carry the same fields already encrypted. Importing one of those encrypts the value a second time and leaves it irreversibly unusable — and the import still reports success, so the problem only surfaces the first time the provider is called.

From this release such a package is refused instead of being silently corrupted: the import stops and you get an error telling you to export the package again from the source installation with a current Apinizer version. Re-producing the package on the source installation is the fix; there is nothing that can be repaired in the old file you already hold.

Connection definitions (mail, LDAP, database, SNMP, Elasticsearch, FTP, RabbitMQ, ActiveMQ and Linux Script) and the identity services are outside this rule: their secret values travel encrypted in the package and are stored on the destination as they are. If a package of one of those types does carry a secret in plain text — a hand-written GitOps file, say, or a package produced from a record that a much older version stored in plain text — the import now stores that value encrypted on the destination. A data repair that runs during the upgrade encrypts values that were already stored in plain text, and leaves values that are already encrypted untouched.

Warning

The integrity record shows that a package was not damaged or altered by accident. It does not prove who produced it: the record travels inside the package, so whoever can change the package can rewrite the record as well.

Only exporting with a passphrase gives you that stronger guarantee — a package that cannot be opened without the passphrase cannot be modified without it either.

Import Permissions and Limits​

Who May Open the Wizard​

The Export/Import screens (Export and Import) require Export/Import in at least one of these categories in your active project: Project Management, API Management, Global Settings, Identity, Secrets, Connections, API Creator, AI Development, AI Budgets, AI Analytics.

Project administrators and system administrators always pass. The Administration menu's Export/Import entries are shown to system administrators once a project is active; only the Import Project page needs no active project (it creates the project). A user holding Export/Import in none of these categories — a project member with only Analytics, for example — does not see the entry in the menu and cannot reach it by typing the address either; they are redirected to the access-denied page. The Import shortcut buttons on the Certificate, KeyStore, Consumer, Connection and API Creator lists follow the same permission: without it the button is not shown, so no shortcut leads to a screen you cannot open. On the 14 non-OTLP connection list screens this button opens the wizard's import step with type Connection preselected — Admin scope when opened from the Administration mount, the active project's scope otherwise.

Being able to open the screen does not decide what you may transfer — the rules below do, and every request is checked again on the server.

Who May Import What​

An import is authorized against the project you are importing into, not against the project the package came from. Two rules apply, in order:

  • If you hold Project Management → Export/Import in the destination project, you may import the whole package.
  • Otherwise each object in the package is checked one by one: for every object you need Export/Import on that object's own category in the destination project. One object you lack permission for stops the whole import, and because the check runs before the first record is written, nothing is left half-imported.

This applies to the wizard, to single-object (JSON) imports and to APIops transfers alike. The check covers every object the package carries: a Consumer, certificate or connection inside an API Proxy package, and the DB/Script/Mock API definition embedded in a proxy, are each asked about on their own category. A user holding only API Management Export/Import, for instance, cannot import an API Proxy package that contains a Consumer — that also needs Export/Import on Identity.

The same rule covers the "create from package" option on the mapping step: the object created there is authorized against its own category, not against the main type you picked in the wizard.

If the package cannot be read — a corrupt ZIP, invalid content or a missing passphrase — the request is refused, because it cannot be authorized; an unreadable package is never treated as one whose permission check may be skipped.

Note

Earlier versions had two gaps here: the per-object check ran only on single-object imports, so a ZIP package was accepted on the destination-project check alone; and in the wizard, a package that could not be read fell back to checking the main object type only, letting the other objects in it be written without a permission check. Both are closed. If your operators import packages into projects where they hold only category-level permissions, confirm those permissions cover every object type in the packages they use — dependencies and embedded API Creator definitions included; where they do not, an import that used to complete will now report a permission error.

Package Size​

An import bounds how far a package may expand: at most 20,000 files, at most 256 MB per file, and at most 1 GB in total. Real exports stay far below these limits. A package that exceeds one of them is refused with an explanatory message; export it in smaller parts.

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.
MCP Source API Proxy Dependency & Mapping
  • When an MCP Gateway exposes another API Proxy's endpoints as tools (Expose Tools mode), each distinct API Proxy behind those tools surfaces as its own dependency, labeled MCP Source API Proxies — this is different from the inline server definition described above (a Passthrough proxy's backend, or a Tool/Agent Call policy's embedded server), which keeps traveling inline as part of the gateway's own package.
  • On import, every source proxy reference is resolved in this order: (1) the mapping you make explicitly on the wizard's mapping step; (2) failing that, exactly one API Proxy in the target project carrying the same name and the same API type; (3) failing that, the copy of the proxy the package carries, when you kept it included on export — that copy is imported as a new object and then bound to the tool. A package re-imported into the very same installation can additionally resolve by the proxy's original id when none of the above applies.
  • Replace Existing on the MCP Gateway itself never replaces the source proxy it resolves to: when the tool binds to a proxy that already exists in the target through step 1 or 2 above, that proxy's own content is left untouched — only the gateway's own definition is replaced. The source proxy follows its own Replace Existing / Import as New choice only when it was also selected as a main object in the same operation.
  • Before anything is written, the import is refused in three cases: the source proxy can't be resolved by mapping, by name+type, or from the package at all (mcpSourceProxyUnresolved); more than one API Proxy of the same name and API type exists in the target, so which one to bind to is ambiguous (mcpSourceProxyAmbiguous); or a tool is pinned to one specific operation (HTTP method + path) of the source proxy and that operation doesn't exist on the proxy the import would bind it to (mcpToolEndpointMissing). Each message names the gateway and the tool and says what to do next — map the tool to the intended proxy on the mapping step, add the missing endpoint there, or export the gateway again with its source proxies included.
  • This dependency requires the destination to be on Apinizer 2026.09.3 or later: a package carrying it cannot be imported into an earlier installation.

An Uptime Monitor's or Anomaly Detector's notification connector — the mail or webhook connection its alerts go out on — is packaged as a dependency the same way any other connector-based reference is, and so is its failover connection, when failover is enabled for it, exactly like a SIEM destination's failover connector (see SIEM Settings below).

Identity and Limit Management Types​

Limit Plan, API Client, Limit Assignment and Access Entitlement are four types added to the wizard's Identity category. They are matched between installations by a stable name or key rather than by an internal record id, so a rename on either side can't turn a match into a mismatch. All four also share one behavior that sets them apart from the rest: import never puts any of them into effect on its own.

Import never makes anything effective
  • Limit Plan — arrives as a Draft plan with a Draft revision holding the packaged rule body. Publishing it on the target is a separate operator action; only then can an assignment use it.
  • API Client — arrives as a Draft client waiting on a secret. A client's secret is never part of the package — issue a new secret for it on the target, then activate it.
  • Limit Assignment — arrives as a Draft assignment. It affects no traffic until you activate it on the target.
  • Access Entitlement — arrives as a Draft entitlement. It grants no access until you activate it on the target.
Limit Plan
  • A limit plan travels as a single file together with the revisions that make up its rule body. It carries no dependency of its own — its rules are made of numeric thresholds and window values, referencing no other object.
  • A plan created with Import as New always starts as Draft; the packaged rule body becomes the plan's first Draft revision. Making the plan effective (publishing) is not part of the import — it's a separate action on the plan's own screen.
  • Replace Existing always updates the target plan's name, description and labels, and tries to add the packaged rule body as a new Draft revision on top of it. That addition is skipped in two cases — the target already has an open draft, or the target plan is retired — and in both, the metadata update still lands while only the rule body is skipped and reported in the import summary.
  • Matching against the target is by the plan's stable plan key, never by its display name. Import as New is refused when that key is already held by another plan in the target — a rename in the Options step does not avoid this; use Replace Existing for it instead.
API Client
  • A typed OAuth client belonging to a consumer or an application can travel. A client has no management screen of its own — it's managed from its owner's (credential's or application's) detail screen.
  • The client's secret material (client secret) never enters the package. An imported client always arrives as Draft and waiting on a secret; its first secret has to be issued on the target, and the client activated, separately.
  • Replace Existing updates only the client's name and issuance settings; the target's secret(s), usage state, suspension/revocation history and counters are left exactly as they are. A Replace whose packaged owner does not match the target client's current owner is refused outright — a client can never be moved to another owner.
  • The client identifier is unique across the whole installation, across every project. If the packaged identifier is already held by another client — even one living in a different project — the import is refused; no new identifier is silently minted.
  • If the client's owner (a consumer credential or an application) cannot be found on the target, or the owner's name matches more than one application there, the file's import is refused rather than creating an ownerless or ambiguously-owned client. When the owner is a consumer, that consumer can be packaged as a credential dependency; when the owner is an application, it must already exist under the same name in the target — applications are not a type this wizard transfers.
Limit Assignment
  • A limit assignment defined for a subject (consumer, API client, application, organization, project, or a rule-based group) can travel.
  • Import never puts a ceiling into effect: a new assignment always arrives as Draft and is never pushed to any Gateway.
  • Replace Existing updates the target's content only while it is still Draft; a target that is already Active or Ended is left untouched and reported in the import summary.
  • Dependencies: the plan(s) it names can be packaged with it; when its subject is a consumer the matching credential can be packaged too, and likewise its own API Client when the subject is one. When the target is a proxy or proxy group, that's a reference only — the target object itself is never packaged and must already exist under the same name on the target. The environment travels by name and is only validated on the target, never translated.
  • The import is refused for that file if the subject, target, environment, or a named plan cannot be resolved on the target — a reference is never silently dropped.
  • An assignment scoped to the whole installation (a PLATFORM subject, belonging to no project) never appears in the wizard's object list and cannot be imported through this wizard.
Access Entitlement
  • A record granting a consumer's or application's access to a proxy, proxy group, API product, or a proxy scoped to a single environment can travel.
  • Import grants no access: a new entitlement always arrives as Draft and affects no Gateway behavior until activated.
  • Replace Existing updates the target's target and validity window only while it is still Draft; an entitlement that is already active or ended is not modified.
  • The import is refused for a file whose packaged subject differs from the target record's — an entitlement can never be moved to another subject.
  • The dependency exists only when the subject is a consumer (the matching credential can be packaged with it); when the subject is an application, or the target is an API product, neither travels — both must already exist under the same name on the target. A proxy, proxy group or environment target is likewise reference-only and never packaged — it is matched by name.
  • The import is refused for that file if the subject or the target (environment included) cannot be resolved on the target — there is no silent skip.

API Product Subscription Plans​

An API Product's subscription plans travel inside the product's own package — they are not a separate object type you select. On import, each plan is re-attached to the imported product and is then treated exactly like a plan saved from the plan screen: the limit profile the gateway enforces is created immediately, so an imported plan applies its rate limit and quota from the moment it exists. No follow-up "open the plan and save it" step is needed, and no plan arrives advertising a ceiling that nothing applies.

  • Import as New gives each plan its own newly generated profile on this installation. A profile the plan referenced on the source installation is never carried over — profiles belong to the installation that enforces them.
  • Replace Existing updates the target plan's own profile in place instead of opening a second one, so every subscription already bound to it keeps resolving the same profile and simply sees the new numbers.
  • When a Replace changes a plan's rate limit, quota, interval or on-exceed behavior, the plan's already-approved subscriptions are resynchronized in the background, so the gateway stops applying the ceiling the package replaced.
  • A packaged plan whose rate limit or quota permits no calls at all (0 or a negative number) is not imported: it is skipped before anything is written for it, and the reason appears among the import report's dropped references. The rest of the package imports normally — one unusable plan does not discard everything else. Correct the plan on the source installation and export again.

Cloning a whole portal (Portal Settings → Clone/Transfer) applies the same rule with one difference: because a portal package's applications and subscriptions reference its plans, an unusable plan refuses the whole clone before the first record is written, rather than being skipped. Nothing is created, and the message names the plan to correct.

SIEM Settings​

SIEM Settings is the wizard's one Admin type: unlike everything else in the catalog, it belongs to no project — there is exactly one of it per installation — and only a system administrator can export or import it, whether through the wizard or through APIops. Because it has no owning project, it never appears in a project's own Export/Import menu; reach it only from Administration → Export/Import.

  • What travels: the whole SIEM & Log Forwarding configuration exports as a single file — every destination (its connector reference, payload profile, size policy, privacy profile and stream rules) and the two local-storage switches. A destination's connector — and its failover connector, when it has one — is a dependency exactly like any other connector-based type: package it along, or map it to an existing connection configuration by name on import.
  • What never travels: a stream's authority (Legacy or Active) is never part of the package and is never changed by an import — only the SIEM & Log Forwarding page itself, on the target, can cut a stream over. The record's server-managed fields (its revision counter, its last-modified stamp) are likewise never carried; the target keeps its own.
  • Replace Existing replaces the target's destination list wholesale with the package's, and takes the two local-storage switches from the package as well. The target's own stream authority is left exactly as it is.
  • Import as New appends the package's destinations to the target's existing list — a name already in use there gets an -imported suffix — and leaves the target's local-storage switches and stream authority untouched.
  • A destination whose connector can't be resolved on the target — the packaged connection wasn't included, and no connection of the same name and type exists there either — still imports, just with Enabled turned off, and the import result names the destination and the connection it couldn't find. It is never silently imported active with a broken reference, and it is never silently dropped. The same applies to a destination's failover connector.
  • A destination created by Import as New that forwards the API Security stream, and that carries no privacy profile of its own, is seeded with the same masking rules a destination created directly on the page gets — see Privacy profile.
  • The privacy salt travels in the package as plain text, unchanged — the same way a connector's salt already travels inside other packages today. This is deliberate: two installations only produce matching hashes when they share the same salt. Because of that, if the package might sit somewhere shared — a CI repository, a shared drive — export it with a passphrase (see Package Encryption above); an unencrypted package leaves that salt, and everything hashed with it, readable to whoever has the file.

Import Advisories Outside the Wizard​

OTLP is the one connection kind that still carries a lightweight, single-file Import dialog directly on its own list screen, under Connection Management: it has no wizard-catalog counterpart at all, so it applies the uploaded package straight away, without this wizard's dependency or mapping steps. The other 14 connection types — Kafka, Webhook, Email, Elasticsearch, database, and the rest listed there — no longer carry this separate dialog: each list screen's row-menu Export and toolbar Import now go through the wizard's own Connection type described above instead. An encrypted package can still be imported through OTLP's dialog: when the uploaded file is passphrase-protected, the dialog asks for the passphrase after the first Import attempt — enter the passphrase the package was exported with and press Import again. A wrong passphrase is reported inline and can be corrected without re-selecting the file.

That dialog now surfaces the same two advisories the wizard's own Review & Import step does — a reference the import could not resolve and had to clear, or a provider's secret that was overwritten because an existing target was replaced — right on the dialog itself, worded exactly like the wizard's. Previously this information only ever reached a server log line, never the screen the operator was looking at.

Transfer API v2 (APIops)​

For a CI/CD pipeline, the same export/import engine is also available as a versioned Management API surface: Transfer API v2. It adds one guarantee neither this wizard nor the plain APIops export/import calls give a script — that what gets applied is exactly what the pipeline inspected, with nothing having moved in between.

The flow is preview-then-apply, in four calls: a preview resolves the export selection (and its dependencies) and hands back a digest; the export run repeats the request with that digest and is refused if the selection would now resolve differently. On the import side, a preflight analyzes the uploaded package against the target project and hands back its own digest; the import run repeats the package with that digest — refused if the target project changed since — and requires an Idempotency-Key header so a retried pipeline step can never apply the same import twice.

This is additive: the existing /export-import/{type}/export|import endpoints keep working exactly as before, for pipelines that don't need the drift check. Full request/response shapes, error keys and a worked curl example are in Transfer API v2.

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