Insomnia 13 closes the gap between API truth and testing

At a glance

What this is: Insomnia 13 links API testing to live Kong Konnect configuration and adds cloud project linting to enforce standards in real time.

Why it matters: It matters because identity and access teams now have to govern API truth, not just API documentation, across human workflows and agentic AI consumers.

👉 Read Kong's release note for Insomnia 13 and native Kong Konnect integration

Context

API testing breaks down when the tool under test is disconnected from the system of record. In this case, the system of record is Kong Konnect, while the practical issue is that developers often work from an API spec that no longer matches live gateway configuration. That creates drift in both human workflows and any automated consumer that relies on the same endpoint context.

For identity and access programmes, the governance question is not just whether the right endpoint exists. It is whether the right version, route, and configuration are the ones actually being used at the point of execution. As agentic AI becomes a consumer of API context, stale specs become an access and behaviour problem, not just a developer inconvenience.

Key questions

Q: How should teams keep API tests aligned with live gateway changes?

A: Teams should connect their test tools to the same control plane that governs production routes and versions. That reduces drift, ensures requests match current behaviour, and prevents teams from validating against obsolete endpoint definitions. The key control is authoritative configuration, not a locally copied spec.

Q: Why do stale API specs create governance risk?

A: Stale specs create governance risk because they let developers and automation test against a version of the API that no longer exists. That can lead to broken integrations, incorrect parameter use, and false confidence in access paths. In practice, the risk is version drift between documentation and live control state.

Q: What do security teams get wrong about API linting?

A: Many teams treat linting as a style preference, but it is actually a policy enforcement control. When rules are embedded in the project and applied consistently, they reduce review dependence and catch non-compliant patterns early. Without that, standards stay aspirational and drift becomes normal.

Q: How should organisations govern APIs used by AI agents?

A: Organisations should govern agent-facing APIs with the same configuration discipline they use for humans, but with stricter validation of schema and route currency. If an agent consumes stale context, it can make repeated bad calls quickly and amplify errors. The control point is current API truth, not the agent itself.

How it works in practice

Live gateway configuration as the source of API truth

API clients and testing tools often depend on exported specifications, but those files age quickly when routing, versions, or request shapes change. Native integration with Kong Konnect changes the control point by pulling the current control-plane state into the testing workflow. That means endpoints, parameters, and config are validated against the live record instead of a copied snapshot. In governance terms, the test surface aligns more closely with production intent, which reduces the chance that teams certify behaviour against outdated metadata.

Practical implication: treat the control plane as the authoritative source for test context and retire manual spec export as the default workflow.

Custom linting for cloud projects and policy enforcement

Linting turns design rules into enforceable checks. Instead of relying on reviewers to remember API conventions, custom rules can stop non-compliant requests or definitions before they spread across projects. In cloud projects, that matters because policy drift usually enters through small exceptions that get repeated. Once rules live in the project and the UI, they become part of the delivery path rather than a separate governance document. The result is less ambiguity about what is acceptable and where violations should be caught.

Practical implication: encode API standards as lint rules for cloud projects so compliance happens during authoring, not after review.

Agentic AI needs versioned API context, not stale specs

When an AI agent calls APIs, it inherits the same dependency on accurate routes and schemas that humans do, but the failure mode is harsher. A stale spec can cause deprecated calls, invalid parameters, or cascading tool errors that are difficult to trace because the agent may continue executing after the first mismatch. This is an API governance issue as much as a model issue. The key control is not just access to tools, but whether the tool context reflects the current gateway state the agent is actually operating against.

Practical implication: validate the API context given to agents against live gateway configuration before allowing autonomous or semi-autonomous execution.

NHI Mgmt Group analysis

API truth drift is now an identity governance problem, not only a developer productivity problem. When testing depends on copied specifications, the organisation loses assurance that the subject under test matches the real access path. That gap affects who can call what, under which route, and with which parameters. For IAM and platform teams, the practical conclusion is that API governance must be anchored to live state, not exported artefacts.

Custom linting makes policy durable only if the policy matches the operating environment. Static API standards do not help when teams keep bypassing them in fast-moving cloud projects. By moving rule enforcement into the workflow, the governance model becomes less dependent on memory and review discipline. Practitioners should see this as a control consistency issue, especially where teams span development, platform, and security ownership.

Agentic AI raises the cost of stale configuration because execution can continue after the first wrong call. A human developer usually notices a broken endpoint quickly. An agent may chain retries, switch tools, or produce misleading output before anyone intervenes. That makes API context quality part of autonomous system governance, and the field needs to treat version drift as a behaviour control failure, not just a documentation defect.

Versioned API context is the named concept practitioners should track. The central issue is not whether the spec exists, but whether the version being consumed matches the live control plane at decision time. That concept connects human developers, platform teams, and agentic consumers through one governance question. The practitioner takeaway is to certify the context source, not just the endpoint inventory.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• From our research: 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security.
• That visibility gap is why teams should also review the NHI Lifecycle Management Guide for offboarding, rotation, and access review discipline.

What this signals

Versioned API context will become a baseline control as more agents consume operational APIs. The practical shift is simple: if a tool cannot prove it is using current routes and schemas, it should not be trusted to execute business-critical work. Teams that already struggle with configuration sprawl should expect that problem to surface faster once AI agents are in the loop.

Insomnia 13 points to a wider pattern in which governance moves closer to the workflow instead of sitting in a separate review layer. That is useful for platform teams, but it also raises the bar for configuration ownership, because the quality of the control plane now determines the quality of the downstream test and execution chain. Practitioners should prepare for more demand for traceable, versioned API context across development and automation estates.

For practitioners

• Bind API testing to the live control plane Use Kong Konnect as the system of record for routes, versions, and request context so tests validate current state instead of exported files.
• Encode API standards as project-level lint rules Move style and governance checks into cloud projects so violations are caught during authoring and not deferred to manual review.
• Check agent-facing API context before execution Verify that any AI agent or automation reads the same route and schema version that the platform team has approved for production use.
• Remove spec export from the default workflow Make manual copy and paste of API definitions the exception, because duplicated artefacts are where version drift starts.

Key takeaways

• Insomnia 13 makes API testing depend on live Kong Konnect state, which reduces drift between documentation and execution.
• Custom linting turns API standards into enforceable controls instead of review-time preferences.
• As AI agents consume API context, teams need to govern version currency and route accuracy as part of access control.

Key terms

• API truth: The authoritative, current record of routes, versions, request shapes, and configuration that defines how an API actually behaves. In practice, API truth should come from the live control plane, not from copied files or outdated documentation, because governance only works when the test and execution context match.
• Version drift: The mismatch between a stored representation of an API and the live system it is meant to describe. Version drift creates false confidence, breaks integrations, and weakens governance because teams validate against a past state while production has already moved on.
• Project-level linting: A policy enforcement approach that embeds API rules inside the project so violations are flagged automatically during authoring or update. It reduces dependence on manual review and makes standards repeatable across teams, environments, and cloud projects.
• Agent-facing context: The route, schema, and configuration information an AI agent uses when calling APIs. If that context is stale or incomplete, the agent can make repeated bad calls quickly, which turns configuration quality into an execution control issue rather than a documentation problem.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or IAM programme development, it is worth exploring.

This post draws on content published by Kong: Insomnia 13 native Kong Konnect integration and real-time API testing. Read the original.