Asset Lifecycle
Asset Lifecycle covers three operations offered in common across most configuration screens in Apinizer: Duplicate, Audit, and Rollback. These operations are accessed from the asset's own list and detail screens — they are not a separate menu or module.
Scope
Duplicate, Audit, and Rollback are enabled on the large majority of configurable assets in Apinizer. The table below summarizes the main asset groups and example assets where these operations are active.
API from Database, API from Script, Mock API
Credentials and Credential Organizations, Contracts/Protocols, IP Groups, Rate Limit Control List
Certificates, Keystores, JWK, Private Keys
Kafka, RabbitMQ, Email, FTP, Elasticsearch, Webhook, Syslog, Graylog, ActiveMQ, and other connector definitions
Variables, Environment Variables, Policy Configuration Templates
Uptime Monitor, Anomaly Detector, Custom Queries and Filters, Report Configurations
Users, Roles, Teams
MCP servers/connections, A2A agents/connections, Knowledge Bases, LLM Providers, Model Catalog, AI policies
Task Flow definitions, API Promotion mapping definitions
Exception for API Proxy: Duplicate on API Proxy follows its own dedicated flow rather than the common flow described below, because the linked definition file and methods must also be cloned separately. That flow is documented on the API List page. Audit and Rollback on API Proxy, however, use the common mechanism described on this page.
Duplicate
Duplicate creates a new, independent record based on an existing asset. The source asset's settings carry over to the new record; only the name changes, and the copy is created with its own identity, independent of the source.
From the asset's list screen, select Duplicate from the row's action menu.
In the dialog that opens, enter a name for the copy. Reusing the source's name, or a name already used in the project, is blocked and a warning is shown.
Once confirmed, a new record is created and the copy appears on the list screen.
The duplicated record inherits the source's configuration, but its deployment state is reset. The copy starts out as a new record that has not yet been deployed to any environment — information about which environments the source is deployed to is not carried over to the copy.
Audit
Every asset that has been saved at least once has an Audit and Rollback tab on its detail screen. This tab only appears once the asset has been saved (it is not shown for a new, unsaved record).
This tab lists every operation performed on the asset, newest first. Each entry shows:
| Field | Description |
|---|---|
| Date | The date and time the operation was performed |
| User | The user who performed the operation |
| Change | The type of operation (created, updated, etc.) |
| Actions | Actions to inspect the record or roll back to it |
Clicking the view (eye) icon on a row shows the full configuration snapshot at that point in time side by side with the previous record's state. Changed fields are highlighted. For an asset's initial creation record, there is no previous version to compare against, and this is noted accordingly.
For assets that change frequently (e.g. a policy that is updated often), the number of listed entries is capped at a fixed limit; the ordering always starts from the most recent entry.
Relationship to the general audit screens
The inspection and comparison mechanism used in this tab is the same one used by Apinizer's platform-wide audit infrastructure. The difference is that it is now also offered as an asset-scoped, filtered view directly on each asset's own detail screen. If you want to review all operations across the system from a single filterable screen, see the Audit Records page. The platform-wide audit screen does not offer a Rollback action — Rollback is only available from the asset's own Audit tab.
Rollback
Rollback restores an asset's configuration to a previous state recorded in its audit history. This action is started from a record in the Audit tab.
In the Audit tab, click the Rollback action on the record you want to restore.
To prevent an accidental rollback, the confirmation dialog requires you to re-type the asset's name. The Rollback button stays disabled until the exact text is entered.
Once confirmed, the configuration recorded in the selected entry is applied to the asset's current state. The asset's identity, project, and creation date are preserved; every other setting is replaced with the values from the selected record.
Rollback does not delete history — instead, it writes a new audit entry. This means the rollback action itself shows up in the Audit history as an "update", and can be rolled back again if needed. The audit history therefore only ever grows forward.
The Rollback described on this page restores an asset's configuration to a prior recorded state. API Proxy also has a separate "Rollback" action that restores which revision is deployed to an environment — that action is performed from the Deployment History on the Deployment and Version Management page and relates to deployment/environment state. The two actions are independent of each other.
Permissions (RBAC)
These three operations are governed by the permission category the asset belongs to:
- Duplicate and Rollback require Manage permission on the asset's category.
- Viewing audit history only requires View permission on the asset's category.
For project-scoped assets (e.g. Credentials, Connections, API Proxy), the permission check is evaluated against the relevant project; for global/project-independent assets (e.g. users, roles), no project scope is required. See the Authorization Matrix page for the full list of categories and role permissions.
Where to Access It
| Operation | Access point |
|---|---|
| Duplicate | The row action menu (...) on the list screen → Duplicate |
| Audit | The Audit and Rollback tab on the detail screen (the record must already exist) |
| Rollback | In the same tab, the Rollback action on a listed entry |
Duplicate is performed from the list screen, while Audit and Rollback are performed from the asset's own detail screen — the three are not all available on the same page.
Next Steps
Review all platform-wide operations with filtering.
Learn about asset categories, actions, and role permissions.
Review the API Proxy-specific Duplicate flow.
Learn how to roll back which revision of an API Proxy is deployed to an environment.