Jentic Tech Talk

Heading to apidays Munich — 10 Sessions on the OpenAPI Track

apidays Munich (July 8–9, 2026) is the next stop for the OpenAPI Initiative Track, and at 10 sessions it’s the largest edition of 2026 so far. The program covers OpenAPI, Arazzo, Overlays, and the intersection of APIs and AI — drawing speakers from across the community to share what they’ve built on top of these standards.

The pattern from earlier 2026 editions has been consistent: Singapore in April, New York in May, and Amsterdam last week (4 sessions) all showed that standards work lands better when it travels alongside real implementation stories rather than spec walkthroughs. Munich extends that pattern with the deepest program of the year. If you’re attending apidays Munich, the OAI Track sessions are worth a look. And if you’ve been thinking about coming, the broader event itself is a strong gathering of the API community.

MCP Is Useful, but Not the End Game — Notes from DevTalks Bucharest

DevTalks Romania (June 4, 2026) gathered a developer audience for a few days of talks across the stack. I went to make a point I find myself making with some regularity these days: as AI moves into real workloads, what changes most isn’t the model — it’s how your APIs expose capabilities to it. MCP gets a lot of attention right now, and it’s a useful piece, but it’s not the end game.

The harder questions sit one layer down: are your APIs in shape for machine consumption (AX, not just DX)? Can workflows be expressed as artifacts agents can actually use, rather than buried in client code? Can agents act safely without holding secrets directly? The talk walks through those questions and a path to “AI-readiness” that doesn’t require throwing away the API estate you’ve spent ten years building. If your APIs are already in good shape, you’re closer than you think.

HTTP QUERY: A 25-Year Workaround Gets an RFC

Every API developer has been here. You need to send a structured query — body-based, complex, too long for a URL. Your options have been: use POST and lose the safety semantics, use GET with query strings and hit implementation-dependent URL length limits, or use GET with a body and hope your HTTP stack doesn’t silently discard it. None of them are right. All of them are common.

RFC 10008 closes that gap. QUERY is now a fully ratified HTTP method: safe, idempotent, body-bearing. It carries the semantics of GET — repeatable without side effects — combined with the payload capacity of POST. Caches can treat it correctly. Clients can retry it safely. And OpenAPI 3.2, which already included QUERY support ahead of ratification, can now point to a published standard rather than a draft.

This one took a while, but I’m very happy it’s here!

Jentic API Scorecard Is Now a GitHub Action

API readiness checks don’t belong at the end of a release cycle. By then, the design decisions that affect agent usability, discoverability, and error handling are already baked in. The Jentic API Scorecard is now available on the GitHub Actions Marketplace, which means readiness feedback can happen where API changes are already reviewed: in pull requests, CI runs, and release workflows to ensure quality is maintained.

The integration is three lines of config. Point it at an OpenAPI spec, set a minimum score threshold, and any PR that degrades readiness gets flagged before it merges. Not as a governance overlay added after the fact — as a quality gate built into the process.

A valid OpenAPI is still necessary, but it’s not sufficient. The question agents, MCP servers, SDK generators, and integration workflows actually need answered is: can this API be understood and used reliably? That’s what the Scorecard surfaces, and it now does so automatically in your existing workflow.

From Contracts to Flows: The Gap Arazzo Fills

Bryam Vega, senior software architect and ThoughtWorks consultant, attended apidays New York and left wanting to understand Arazzo deeply. The result is one of the clearest practitioner write-ups on what the spec actually solves.

His framing is sharp: the problem isn’t bad API contracts. It’s that contracts don’t talk to each other. OpenAPI documents endpoints. It says nothing about what comes before or after. Authentication first, then product search, then cart, then order — that sequence lives in developers’ heads, integration tests nobody reads, or nowhere at all. In large organisations that invisibility multiplies: ten teams consuming the same API sequence produce ten different implementations with ten different failure handling strategies.

Arazzo makes the flow the artifact. Step dependencies, data propagation between calls, explicit success criteria, failure routing — all declared, versioned, and machine-readable. Vega built a real demo around an 8-workflow credit card system and open-sourced 116 Spectral rules for Arazzo governance, each citing the spec. That combination — a worked example plus enforceable linting — is exactly the kind of ecosystem maturity Arazzo needs to move from interesting standard to production practice.