Jentic

Are you heading to Dublin Tech Summit this week in The RDS? Come along to my session on the Main Stage on Thursday at 1pm for "Engineering in the Age of AI". I'll be joined by Josh Builder from Datavant, and Brendan O'Reilly from Boldyn Networks, with Ryan Woods from Started PR moderating. We’ll be talking about how engineering is changing in practice, not just in theory. How teams are working differently, which skills are becoming more valuable, what companies are getting wrong, and what engineers need to do to stay relevant as the role continues to shift, as well as real-life examples of what we're implementing at Jentic. Looking forward to seeing you there! #dublintechsummit #dublintechweek

𝗧𝗵𝗲 𝗪𝗲𝗲𝗸𝗹𝘆 𝗦𝗶𝗴𝗻𝗮𝗹 | 𝗔𝗣𝗜 𝗔𝗜-𝗥𝗲𝗮𝗱𝗶𝗻𝗲𝘀𝘀 | 𝗦𝗶𝗴𝗻𝗮𝗹 #𝟲: 𝗔𝘂𝘁𝗵 𝗦𝘁𝗿𝗲𝗻𝗴𝘁𝗵 An #agent doesn't just need to know that your #API requires authentication and the right authorization. It needs to understand how to authenticate safely, with the right mechanism, the right scope, and the right trust model. That information lives in your #OpenAPI description, or it doesn't, meaning consumers have to go out-of-band to discover the information. 𝗧𝗵𝗲 𝗦𝗶𝗴𝗻𝗮𝗹: 𝗮𝘂𝘁𝗵_𝘀𝘁𝗿𝗲𝗻𝗴𝘁𝗵 `auth_strength` scores the average strength of all declared security schemes — from plaintext credentials to cryptographically bound identity. Agents act on this directly and at scale, without the human fallback of reading docs or asking colleagues. • HTTP Basic: 0.10 — credentials on every request, easily leaked • apiKey (query): 0.15 — leaks into logs, URLs, proxies • apiKey (header): 0.50 — moderate; no scoping or rotation • OAuth2 clientCredentials: 0.85 — scoped, strong, right for M2M • OAuth2 authorizationCode (PKCE): 0.90 — most secure OAuth2 flow • OpenID Connect: 1.00 — solid standard, identity-bound access 𝗧𝗵𝗿𝗲𝗲 𝗔𝗣𝗜𝘀. 𝗩𝗲𝗿𝘆 𝗗𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗦𝗰𝗼𝗿𝗲𝘀. Spotify Web API scores 90% `89` operations with #OAuth2 authorizationCode grant-type. Scoped, renewable, machine-readable. A consumer requests precisely the permissions it needs — `playlist-read-private`, `user-read-email` but nothing more. PagerDuty API scores 50% `420` operations. apiKey in header. In practice it offers read-only key flags, RBAC-scoped User Tokens with fine-grained permissions but none of it visible from the OpenAPI Description. The description says `apiKey in header` and stops. The 50% reflects what the spec tells an agent — not what the platform can do. Zendesk Support API scores 10% `489` operations. HTTP Basic. Every call transmits base64-encoded credentials — no OAuth, no scopes, no rotation. Static, unscoped, and irrevocable across 489 operations. 𝗪𝗵𝗮𝘁 𝗚𝗼𝗼𝗱 𝗟𝗼𝗼𝗸𝘀 𝗟𝗶𝗸𝗲 OAuth 2.0 with scopes is a solid baseline. For M2M: clientCredentials. For user-delegated: authorizationCode + PKCE. Declare scopes in the spec. If you're still on Basic or unscoped keys, migrate now. New agent-based standards like SPIFFE and AAuth are emerging to add even more rigor for agent API consumers. Agents need verifiable identity. Surface the auth model in the API contract. This is Signal #6 in a weekly series on Jentic API AI-Readiness Scoring. Each week: three real APIs, one signal, open scorecard data. Framework: https://lnkd.in/dm8JYJsa Score your API: https://lnkd.in/d-Yt6cXV #TheWeeklySignal #APIReadiness #OpenAPI #AIReadiness #AgentExperience #APIsAreForever #APISecurity

𝗧𝗵𝗲 𝗪𝗲𝗲𝗸𝗹𝘆 𝗦𝗶𝗴𝗻𝗮𝗹 | 𝗔𝗣𝗜 𝗔𝗜-𝗥𝗲𝗮𝗱𝗶𝗻𝗲𝘀𝘀 | 𝗦𝗶𝗴𝗻𝗮𝗹 #𝟱: 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗲 𝗖𝗼𝘃𝗲𝗿𝗮𝗴𝗲 A well-documented #OpenAPI response surface is foundational developer experience. Described outcomes let developers harden client integrations against the full range of what an API can return: success flows handled correctly, error paths explicit, nothing falling through silently. For an #aiagent, that same documentation enables efficient planning before execution and prevents silent failure at runtime. An agent acting autonomously on behalf of a user has no such fallback, and in multi-step workflows, one undocumented failure cascades into several. This week's question: beyond the success case, how much of your API's response landscape have you actually documented? 𝗧𝗵𝗲 𝗦𝗶𝗴𝗻𝗮𝗹: 𝗿𝗲𝘀𝗽𝗼𝗻𝘀𝗲_𝗰𝗼𝘃𝗲𝗿𝗮𝗴𝗲 `response_coverage` measures the percentage of operations with complete response definitions, scored per operation across four categories: • +0.25 if one 2XX response is defined • +0.25 if one 4XX response is defined • +0.25 if one 5XX response is defined • +0.25 if a default is defined Each category is a distinct decision branch. Leave one undocumented and agents, and developers, have one fewer known path to act on. 𝗧𝗵𝗿𝗲𝗲 𝗔𝗣𝗜𝘀. 𝗩𝗲𝗿𝘆 𝗗𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗥𝗲𝘀𝘂𝗹𝘁𝘀. DigitalOcean API gets 100% 589 operations, essentially every one documents all four response categories. An agent managing droplets, load balancers, or Kubernetes clusters knows exactly what to expect at every step. At that scale, this kind of completeness doesn't happen by accident. Okta Admin Mgmt API gets 50% 727 operations with half the response landscape documented on average. Consumers use this API to provision users, manage access policies, and configure OAuth clients. Knowing whether a failure is a permission boundary, a rate limit, or a server fault requires different handling. On half of Okta's operations, those distinctions aren't documented. #HuggingFace Hub API gets 20% 235 operations, 80% with no documented response signal. The sharpest irony: HuggingFace builds the model infrastructure that powers AI agents, and the Hub API is one of the most agent-relevant APIs in existence. Yet the agents using it have almost nothing to act on when calls go wrong. 𝗪𝗵𝗮𝘁 𝗚𝗼𝗼𝗱 𝗟𝗼𝗼𝗸𝘀 𝗟𝗶𝗸𝗲 Document all four response categories on every operation. For 4XX, cover at minimum 400, 401, 403, 404, and 429 so agents can distinguish bad input from auth failure from rate limiting. If you already use RFC 9457 Problem Details for error bodies (Signal #2 in this series), the structure is there, the remaining gap is coverage. This is Signal #5 in a weekly series. Each week: 3 real APIs, 1 signal, & open scorecard data Jentic Framework: https://lnkd.in/dm8JYJsa Score your API: https://lnkd.in/d-Yt6cXV #TheWeeklySignal #OpenAPI #AIReadiness #AgentExperience