Like the rise of northern light sightings worldwide, Nordic APIs is something awe-inspiring from the north that’s starting to seep into regions globally. The API-first mindset encourages openness and inspiration, and many are looking to it as a north star for next-generation application development. This truth was evident last week in Stockholm.

From October 7-9, 2024, the international Nordic APIs community reconvened in Stockholm, Sweden, for our ninth annual Platform Summit. The event brought together some of the top minds from the global API industry, Nordic countries, and the greater EU region to discuss countless topics across the API spectrum, such as new description languages, emerging security threats, management and business techniques, and more.

What stood out to me was the barrage of interest in AI and the urgency to establish API connections as the orchestration layer for this new movement. Below, I’ll review some of the key takeaways from discussions and sessions I attended. This is not exhaustive, and we’ll soon explore other topics inspired by the event. But I hope it gives readers a taste of what’s on top of mind.

Axel Grosse from 42Crunch discusses design tips to improve your API security posture.

APIs Must Enable AI, Or Else…

Autonomous AIs need access to standardized APIs under the hood, or else they will find workarounds involving screenscraping and robotic process automation (RPA). Both are insecure, unstable integration methods I thought the industry grew out of long ago. However, according to Zdenek “Z” Nemec, founder and CTO of Superface.ai, large action models (LAMs) could potentially displace the need for API integrations altogether.

Accessing data over UI is often easier, faster, and cheaper than APIs. This is, unfortunately, a result of inaccessible APIs for popular websites and apps, from Instagram to LinkedIn, Salesforce, and beyond, he says. It can be hard or near impossible for a startup with an app idea to convince a major organization to provide APIs for a particular feature, leaving them to explore alternatives. “Get APIs right, or people will either use LAM or walk away,” says Z.

Andrew Carlson, Principal Field Architect, Apollo Graph, suggests training AI agents on how to interact with APIs, as opposed to wasting massive power-hungry operations feeding them massive datasets. Careless AI use could even lead to an entirely novel threat — an economic denial of service (DDoS) attack, in which hackers bloat consumer-facing AIs to drain resources, causing high financial costs.

My takeaway is that we need more standardized, comprehensive APIs with accurate descriptions for APIs to empower AI agents with safer connections to real-time data. With more awareness of the business benefits of API strategies and specification-driven development, this future seems more feasible.

It’s also good to note we are in the early stages of AI. ChatGPT went from zero to one million users in five days. And although this seemed like an overnight sensation, it was more of a watershed moment, says Kristen Womack, Principal Product Manager at Microsoft. Similar to all the trial and error it took to get the steam engine right, she reminded us there’s been a lot of progress made to get us to this moment in AI. And history is still being made.

Kristen Womack, Principal Product Manager at Microsoft, reminds us we’re in the early stages of the AI revolution.

Complexity Complicates Access Control

In my opening keynote, I mentioned how large enterprises now face a sprawling technology portfolio comprised of various design formats, gateways or management solutions, and differing internal styles. There’s often a spread of customer-facing, partner, and internal APIs, each with varying degrees of openness. This complexity is proving to have security repercussions.

For instance, internal complexity can make it challenging to track and stitch together things like user identity throughout the entire system. Since a typical API breach can lead to ten times more leaked data than an average security breach, quality access control here is crucial. According to Jacob Ideskog, CTO at Curity, adopting OAuth within a token-based architecture is essential to limit access to APIs based on users and the application. He recommends tightening “tent” applications on the periphery of your internal fortress, specifically integrations, web apps, and mobile apps.

Jacob Ideskog, CTO of Curity, explains how to harden API access control for applications on the periphery.

In our panel discussion on API security and authorization, we featured Ideskog, along with Anders Eknert from Styra, and APIsec University‘s Dan Barahona. Some of my takeaways from the discussion were that API attacks are on the rise, and hackers are targeting broken access control as low-hanging fruit. Therefore, organizations should unify segmented policies and begin thinking more about the possibility of data overexposure earlier on in the design process. Plus, security and development teams need to talk more.

Alternative API design styles also pose threats in different ways. For example, GraphQL introspection can be a potential risk. 50% of attacks on GraphQL APIs begin with introspection, says Confidence Staveley, founder of MerkleFence. While there are developer efficiency benefits of keeping GraphQL’s native introspection feature enabled, she argues it’s a security risk and a low-hanging fruit for attackers that could expose sensitive endpoint details that weren’t intended to be live.

Our panel discussion on authorization sparked an insightful dialogue on API security.

TypeSpec, Arazzo, OpenAPI, Oh My

This year’s Platform Summit hosted our first-ever track dedicated to TypeSpec, a new API description language open-sourced by Microsoft. Multiple speakers described how TypeSpec can aid design-first API development by reducing cognitive load and improving reusability. For instance, one clear benefit is that TypeSpec is slimmer. Cailin Smith, Senior Software Engineer, Microsoft, showed the same description in TypeSpec (30 lines) versus OpenAPI (60 lines). A reduced size helps avoid information overload, especially as you scale into the scale of millions of lines of code.

Another point made clear was that TypeSpec is not a replacement for OpenAPI Specification — they can work in tandem. Before the conference, Daniel Kocot, Head of API Consulting at codecentric AG, gave a provocative interview about living in the post-OpenAPI era, stating that developers shouldn’t actually have to directly edit OpenAPI definitions — they should just be generated artifacts.

Should we throw OpenAPI out and go 100% code-first? No. What Kocot means to say is specs like OpenAPI are hard to understand for ordinary software developers, especially citizen developers. Manually editing them is tedious and error-prone. He views TypeSpec as a helpful in-between layer to improve efficiency and automate repetitive tasks.

Next, Chris Wood, Principal Architect at Ozone API and infamous Nordic APIs blogger, gave us a tour of how TypeSpec could greatly benefit API standards in open finance. Version decorators, for instance, let standards authors create one version of truth and render all versions from the same place, he says. He also notes benefits in separation, reusability, and parity with schema objects. However, he’s found that security schemas and certain fields are still lagging.

Speakers also highlighted the new Arazzo specification from the OpenAPI Initiative. According to Budhaditya Bhattacharya, Developer Advocate at Tyk, Arazzo provides a standard method for linking up multiple API calls with a step-by-step process and reusable components. This could greatly help AI agents with a more deterministic way to consume APIs, he says. More use by tooling providers, support for more use cases, and more community discussion appear to be on the roadmap for Arazzo.

Big thank you to API storyteller Budhaditya for all his participation at Platform Summit.

Evolutions in DX: Platform Engineering, New Interfaces, and Cultural Shifts

At the event, I moderated an excellent discussion on developer experience featuring Microsoft’s Womack, Kristof Van Tomme, co-founder and CEO at Pronovix, and Ken Hussey, VP of Engineering at Ambassador. My takeaway was that DX is unique from traditional UX and must be rooted in end business outcomes.

For APIs to have a good developer experience, they should be findable, discoverable, and self-service, with — surprisingly — the right dash of friction, says Van Tomme. Enough friction to learn and retain the basics while streamlined enough to quickly reach “Hello World.” He also stresses that we should think beyond APIs to consider other interfaces that could be represented within your developer portal since this can help cater to new consumer use cases.

Did you know Gartner predicts that 80% of large software engineering organizations will establish platform engineering teams by 2026? Here, developer experience and APIs play key roles. According to live polling at Platform Summit, our attendees feel the top benefits of platform engineering are better developer experience, improved consistency and scalability, and better security and compliance. Francesco Burns, VP of Product at Gravitee, believes self-service internal developer platforms (IDPs) for platform engineering must also bring together disparate platforms and APIs under the hood. REST is still dominant, but we’re seeing things becoming increasingly event-driven.

There is also the company culture to consider, which could indirectly affect the developer experience. Claire Barrett, Director and Founder of APIsFirst and leader of Women in APIs, gave a keynote on the benefits of enhancing diversity and inclusivity in tech. “More diverse teams deliver better on innovation,” she says. “Teams solve problems faster when they’re more cognitively diverse,” also reports Harvard Business Review. For API teams, this can translate into making your service more accessible to a wider audience.

Claire Barrett shares her journey toward encouraging diversity in the API community.

Governance and Management

Also of note at Platform Summit were the handful of sessions looking into new tactics to manage today’s swelling API portfolios. (“Governance” is becoming less of a dirty word these days). One outcome that often requires re-evaluation in an API-heavy environment is a lack of ownership. According to Ivo Stankov, Head of Hybrid Integration, Platforms and Design at OMV AG, “Each API product needs to have an owner.” This is a simple statement, but one that’s not easy to achieve, he says.

A recent study from Salt Security, the State of API Security Report, showed that zombie APIs are now a top concern compared to other risks. Poor API inventory management is likely a root cause here, influencing a greater focus on API governance. I think the trick will be to automate things like linting, style conformance, or contract testing so that it does not feel like a burden to developers.

“Going forward, API engineers must have skills for strategic thinking around APIs,” said API strategist Paul Dumas in his keynote Managing API Management. He looked at three case studies of API management and what succeeded or what went wrong. He emphasized the importance of sharing stories around specific API journeys, which resonates with me. Compared to bullet points, stories contain a larger “payload,” like metadata, which helps folks recall information and refine their process.

So, share stories, keep an ongoing log of your efforts, and build your personal skills. Don’t rinse and repeat with every project or job shift. Maybe this means keeping a secret API style guide on your personal laptop that you whip out from org to org (shout out to someone who told me they do this 😉).

API strategist Paul Dumas shares tips for effective API management.

The Nordics Lead In API-First

One thing is sure — although we say Nordic APIs is a global brand, and most certainly it is, the Scandinavian region is undoubtedly a place where APIs shine. The Nordics has long since been a leader in cutting-edge, open digital technologies, and the attendance at Platform Summit demonstrates the ongoing commitment to API-first strategies across sectors.

We had 60+ speakers, and the event brought together about 250 total attendees, including architects and other tech leads from industries like banking, FinTech, government, manufacturing, consumer-facing brands, and more. In addition to the talks mentioned above, we also looked at edge deployments, quantum computing, Internet of Things (IoT) design, how to monetize APIs, and other areas.

Help Us Improve Platform Summit!

Have a comment? Let us know!

Thank you to our speakers, attendees, sponsors, organizers, and event hosts for making this such a seamless Summit! The feedback we’ve received so far is amazing and drives home our commitment to making the world programmable.

That said, we’re open to any additional feedback to improve the attendee, speaker, and sponsor experience. If you have comments, please participate in the survey that was sent to your email! We’d really appreciate anything you have to share — both positive or negative (hopefully with constructive feedback) 🙂.

Nordic APIs: Your North Star for API Strategy

We’re working on solidifying event dates for 2025, so stay tuned for announcements. Until then, be sure to subscribe to our newsletter for a bi-weekly digest of API strategy right in your inbox. We also encourage you to share your story with us — information about contributing to the blog can be found here. For other ways to become involved, contact us here. Thanks, until next time.