Notifications
Clear all
Topic starter
24/06/2026 8:39 pm
TL;DR: API endpoints power more than 57% of internet traffic, but weak standardisation still creates brittle integrations, inconsistent status handling and avoidable maintenance cost, according to Kong. The security and governance question is no longer just how endpoints work, but how well identity, authorisation and change management keep pace with modern API estates.
NHIMG editorial — based on content published by Kong: Exploring API Endpoints in Depth
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams govern API endpoints in mixed human and machine environments?
A: Treat endpoints as identity boundaries, not just application routes.
Q: Why do API endpoints become a governance problem when organisations adopt more automation?
A: Automation increases the number of callers that can invoke APIs without a human in the loop, which makes route design and authorisation quality more important.
Q: What breaks when API endpoint design is inconsistent across teams?
A: Inconsistent endpoint design breaks predictable authorisation, documentation and monitoring.
Practitioner guidance
- Inventory endpoints by identity sensitivity Classify routes by the identities that use them, including humans, service accounts and automation.
- Standardise methods and status handling Define approved HTTP methods, response codes and resource naming patterns for each API domain.
- Scope OAuth and API key use separately Use OAuth for delegated, scoped authorisation and reserve API keys for narrow client identification where appropriate.
What's in the full article
Kong's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on URI naming, versioning and request-response structure for implementation teams.
- Detailed comparisons of REST, GraphQL, gRPC and SOAP for teams choosing an API pattern.
- Specific examples of HTTP status code use, caching strategies and pagination design.
- Practical security considerations for authentication, rate limiting and validation at the endpoint layer.
👉 Read Kong's guide to API endpoint design, security and trade-offs →
API endpoints in depth: are your design controls keeping up?
Explore further
25/06/2026 5:22 am
API endpoints are an identity control surface, not just a developer interface. The article correctly frames endpoints as the place where request semantics, authentication and transport all meet. That makes them part of IAM and NHI governance, because service accounts, API keys and workload identities are enforced or broken at the route level. Practitioners should treat endpoint design as a control-plane decision, not a documentation task.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: How do you know if API endpoint security controls are actually working?
A: Look for consistent method enforcement, low rates of anomalous requests, clear separation between read and write operations and stable auth outcomes across services. If the same credential can reach unexpected routes or if the gateway allows behaviour that the design never intended, the control is only partially effective.
👉 Read our full editorial: API endpoints in depth: standards, design and security trade-offs
