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 six 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
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.

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, 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 package whose contents changed after export — a file edited by hand, a file added to it, a file removed from it — is refused with an explanatory message, and nothing at all is written. Because the check runs before the first record is saved, a refused import never leaves half-imported data behind. (An edited file's content can be explicitly accepted to let the import proceed anyway — see Acknowledging a Checksum Mismatch below; an added or removed file cannot.)
  • Packages produced by earlier Apinizer versions carry no such record. They keep importing exactly as before; the check simply does not run for them.
  • A package produced by a newer version, in a package format this installation does not know, is refused with a clear message instead of being read halfway.
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.

Acknowledging a Checksum Mismatch​

A plain content mismatch — a file whose bytes no longer match the record, while every file the record declares is still present, nothing missing and nothing extra — doesn't have to end the import. Both the wizard and an APIops call let you explicitly accept the difference and continue: the wizard shows you the warning and re-submits the import once you confirm it, and over APIops the same confirmation is a request parameter. The single-file Import dialogs outside the wizard behave the same way — 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): the warning appears when the package is opened, and 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 warning; there the package is checked before the project is created, so a package you do not acknowledge leaves no empty project behind. Once acknowledged, the import proceeds normally, and the fact that you overrode the check — together with your user name — is written to the operational log, so the decision stays traceable even though it doesn't interrupt the import itself.

This acknowledgment covers a content mismatch only. A manifest that can't be read and a file set that doesn't match its own record — a declared file that's missing from the package, or a file the record never mentions — are always rejected outright; there is no acknowledgment for either of those, because a missing or undeclared file is exactly the silent loss this check exists to catch in the first place.

Over APIops, see Import Objects for the acknowledgeChecksumMismatch parameter 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.

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 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 package (ZIP) imports exactly as it does to single-object (JSON) imports.

Note

Earlier versions ran the per-object check only on single-object imports; a ZIP package was accepted on the destination-project check alone. 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.

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.

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.

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​

Every Connection type — Kafka, Webhook, Email, Elasticsearch, database, and the rest listed under Connection Management — is outside this wizard's type catalog and instead carries its own lightweight, single-file Import dialog directly on its own list screen (see each connection type's own page, for example Kafka). It applies the uploaded package straight away, without this wizard's dependency or mapping steps. An encrypted package can be imported there too: 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