Notifications
Clear all
Topic starter
24/06/2026 9:03 pm
TL;DR: Local-first storage, Git sync, offline CLI automation, and unlimited collection runs remove workflow friction for developers, according to Kong. The identity question is where API clients, secrets, and automation boundaries should sit when operational convenience collides with control and traceability.
NHIMG editorial — based on content published by Kong: 6 Reasons Why Kong Insomnia Is Developers' Preferred API Client
By the numbers:
- With 350+ community-built plugins, chances are someone’s already built the functionality you’re looking for.
Questions worth separating out
Q: How should teams govern secrets inside local-first API tools?
A: Teams should treat API client storage as a sensitive secrets environment, not a casual developer workspace.
Q: Why do Git-native API workflows change IAM oversight requirements?
A: Git-native workflows move API definitions, environments, and tests into standard software delivery controls, which is useful only if live credentials stay out of the repository.
Q: What do teams get wrong about offline API automation?
A: They often treat offline CLI automation as a developer convenience issue rather than an identity governance issue.
Practitioner guidance
- Inventory API client storage locations Map where requests, environments, test data, and auth helpers are stored on developer endpoints, synced repositories, and backup systems.
- Separate design artefacts from live credentials Keep OpenAPI specs, request collections, and environment variables in different trust zones so secret material is never treated like ordinary source code.
- Scope machine identities for CLI automation Bind automated linting and contract testing to narrowly scoped machine credentials with explicit environment boundaries and no unnecessary write permissions.
What's in the full article
Kong's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how Insomnia handles local storage, Git sync, and offline CLI workflows.
- Developer-facing walkthroughs of collection runs, scratch pad use, and plugin extensibility.
- Product-level comparison details on how the tool positions itself against cloud-centric API clients.
- Workflow examples showing how teams can run API testing through Git and CI/CD.
👉 Read Kong’s analysis of why developers prefer Insomnia for API workflows →
Local-first API workflows: what IAM teams should watch?
Explore further
25/06/2026 6:02 am
Local-first developer tooling shifts identity risk from shared platforms to endpoints. When requests, environments, and specs live on a workstation by default, the governance problem is no longer only central policy enforcement. It becomes the durability of secrets on laptops, in backups, and in copied workspaces. That makes endpoint control part of identity governance, not just device management, and practitioners should treat API clients as part of the secrets exposure surface.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How can organisations reduce risk from developer API clients?
A: They should include API clients in their secrets, endpoint, and lifecycle governance. That means understanding where data is stored, how it is synced, who can export it, and which machine identities the tools use. The goal is to keep testing workflows fast while making identity material explainable and reviewable.
👉 Read our full editorial: Insomnia’s local-first API workflow raises identity control questions
