TL;DR: Insomnia 12.6 adds native Git CLI support for API workspaces, expands dynamic mocking to cloud-hosted mock servers, and extends unmanaged-user export and deletion controls, according to Kong. The release matters because it folds API testing, collaboration, and admin cleanup into workflows security and platform teams already use, rather than forcing separate tooling layers.
At a glance
What this is: Kong’s Insomnia 12.6 release brings Git-native API workspace handling, cloud-hosted dynamic mocking, and stronger unmanaged-user cleanup controls into one developer workflow.
Why it matters: It matters because API teams increasingly govern testing, collaboration, and cleanup through identity-adjacent workflows, where repository discipline and admin control shape operational risk.
Context
Insomnia 12.6 is about bringing API testing closer to the tools teams already use for code and collaboration. Instead of treating API workspaces as a separate island, the release stores collections in Git-friendly files, supports terminal-driven edits, and keeps changes in sync across local files and the Insomnia workspace.
The governance angle is stronger than the feature list suggests. When API definitions, mocks, and user administration sit closer to source control and directory hygiene, the team’s operational model shifts toward reviewable change, traceable configuration, and faster cleanup of stale access and content.
Key questions
Q: How should teams govern Git-based API workspaces without losing developer speed?
A: Treat API definitions like code: store them in version control, review changes through branches or pull requests, and make merges the point where policy and quality checks are enforced. That keeps collaboration fast while preserving traceability over who changed what and when.
Q: Why do static mock responses become a problem for API testing?
A: Static responses hide input-dependent behaviour, so tests can pass even when real integrations depend on changing identifiers, derived fields, or request-sensitive logic. Dynamic mocking is useful when you need the test surface to behave more like production instead of replaying the same payload every time.
Q: What should administrators do when unmanaged users appear in a collaboration platform?
A: Export the unmanaged-user list, reconcile it against the identity provider, and decide whether each account should be reattached, reviewed, or removed. The key is to close the gap between actual use and governed ownership before stale access accumulates.
Q: What is the difference between local project cleanup and shared remote deletion?
A: Local cleanup removes a developer’s own working copy or cached state, while shared remote deletion affects the canonical project data used by the team. The distinction matters because resetting local drift should not erase collaboration history or break other users’ workflows.
How it works in practice
Native Git CLI support for API workspaces
Insomnia 12.6 stores collections and workspaces in a file format that works with Git, then reflects file changes in the app in real time. That means the API workspace is no longer trapped inside a UI workflow: developers can use git status, git diff, git commit, git pull, and git push directly from the terminal or editor. The technical shift is not just convenience. It turns API definitions into reviewable artifacts that can move through the same branch and merge controls as code.
Practical implication: treat API specifications as versioned change assets and subject them to the same review and merge discipline as application code.
Dynamic mocking in cloud-hosted mock servers
Dynamic mocking evaluates a response at request time instead of replaying a fixed payload. In practice, the mock can read incoming data, alter fields based on request content, and generate fresh values such as identifiers or email addresses on each call. Moving that behaviour to cloud-hosted mock servers matters because it separates response realism from local-only setup. The control point is not the mock itself but the predictability of the test surface, which helps teams simulate more realistic integration paths without hardcoding every response.
Practical implication: use request-time mocks where downstream testing depends on input-sensitive responses and changing identifiers.
Unmanaged-user cleanup and project deletion controls
The unmanaged-user export function gives administrators a full list of unmanaged users for a domain, which makes reconciliation against the identity provider much easier. The deletion controls add more precise state management, letting teams remove local copies, clear stale cloud data, or reset a project without unintended side effects on the shared remote project. These are lifecycle controls in miniature: visibility, reconciliation, and controlled removal are all part of keeping a collaboration surface from drifting away from actual ownership.
Practical implication: reconcile unmanaged users against the identity provider and define deletion rules for shared projects before stale state accumulates.
NHI Mgmt Group analysis
Git-native API workspaces turn API change control into a governance problem, not just a developer preference. Once API definitions live as files in a repository, the security model shifts from point-in-time UI edits to reviewable, branch-based change. That improves traceability, but it also means teams must govern who can alter the specification, merge it, and promote it across environments. The practitioner takeaway is to treat API workspace structure as part of access governance, not just tooling choice.
Dynamic mocking exposes a familiar testing blind spot: realism depends on request-time behaviour, not static payloads. A fixed mock can validate happy paths, but it will not surface how systems behave when inputs change, identifiers vary, or fields are derived at runtime. This is especially relevant for teams testing APIs that later sit behind automated clients or agent-driven workflows. The implication is to align mock design with the variability of production interfaces, not just with developer convenience.
Unmanaged-user exports are a lifecycle control, not an admin reporting nicety. Exporting unmanaged users creates the evidence needed to reconcile identity provider records against active usage and cleanup obligations. Without that step, teams end up with accounts that are neither clearly owned nor clearly removed. The governance lesson is simple: visibility into unmanaged access is the prerequisite for removing it.
Git discipline and identity discipline are converging in API operations. The same workflows that improve developer velocity also create clearer boundaries for review, rollback, and cleanup. For practitioners, that means API platforms are increasingly judged by how well they fit change management, not by how many separate buttons they expose. The opportunity is to make API collaboration auditable by default, while preserving the speed teams expect.
What this signals
Git-native API testing is becoming a change-control pattern. Once API specs and collections behave like code, teams can apply branch protection, review discipline, and rollback logic to testing artefacts. That is a meaningful governance shift because it reduces the number of places where API change can hide.
Dynamic mocking changes the quality of test evidence. Teams that rely on fixed payloads may validate syntax but miss behaviour that only appears when responses are generated from live request context. The practical signal is that test realism now depends on how closely mocks mirror request variability.
Unmanaged-user cleanup is part of identity hygiene, not just license administration. When collaboration tools expose user export and deletion controls, the goal is to align platform state with the identity provider and remove access that no longer has an owner. That reduces drift before it becomes an audit problem.
For practitioners
- Treat API workspaces as versioned assets Store API collections in source control, require branch-based review for changes, and use diffs to validate specification edits before merge.
- Use request-time mocks for integration testing Prefer dynamic mocks when downstream behaviour depends on request content, varying identifiers, or field transformation at runtime.
- Reconcile unmanaged users against the identity provider Export unmanaged-user lists for each domain, compare them with the identity provider, and define a cleanup path for accounts that no longer have an owner.
- Define deletion rules for shared projects Separate local cleanup from shared remote deletion so developers can reset stale state without unintentionally removing collaboration data used by others.
Key takeaways
- Insomnia 12.6 folds API testing into repository-style workflows, which changes the control model from isolated UI edits to reviewable change.
- The release also extends mock realism and admin cleanup, showing that API tooling now intersects more directly with governance and identity hygiene.
- For practitioners, the main decision is how to make API collaboration auditable without slowing developers down.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Git-native workspaces and mock server behaviour affect API configuration and test surface safety. |
| Recommendation — Apply API8 discipline to keep API workspace and mock configurations reviewable and consistent across environments. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Unmanaged-user export and cleanup map to governed access and entitlement review. |
| Recommendation — Use PR.AA-05 to reconcile unmanaged users against active access and remove orphaned entitlements. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article’s unmanaged-user cleanup concerns account ownership and lifecycle hygiene. |
| Recommendation — Apply CIS-5 to inventory unmanaged accounts and remove access that no longer has an owner. | ||
| MITRE ATT&CK | TA0003;TA0006 — Persistence; Credential Access | Versioned API workflows and exposed user state affect how credentials and persistence risks are governed. |
| Recommendation — Map exposed collaboration state to TA0003 and TA0006 when reviewing how access and persistence are controlled. | ||
Key terms
- Git-Native API Workspace: A Git-native API workspace stores collections or specifications as files that can be edited, diffed, committed, and merged through standard source control workflows. For practitioners, the point is not convenience alone. It is turning API change into a reviewable, auditable artefact with familiar developer controls.
- Dynamic mocking: Dynamic mocking is a test pattern where a mock server evaluates request context and shapes its response at runtime instead of returning a fixed payload. It improves realism for API testing, but it also creates a live configuration surface that needs review, access control, and change tracking.
- Unmanaged user: An unmanaged user is an account that exists in a tool or platform but is not fully governed by the primary identity source or lifecycle process. These accounts can create audit gaps, licensing waste, and revocation blind spots when ownership or employment status changes.
- Local State Reset: A local state reset removes a developer’s working copy or cached project state without necessarily affecting the shared remote source of truth. In collaborative API tools, that distinction matters because teams need a safe way to clear drift locally while preserving canonical project data and history.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org