The Cloud Native AI Summit is landing in Melbourne (Oct.28-29) and Paris (Dec.2-3) and we are excited to announce that our Call For Papers open and is running until August 14th!

As a technical independent conférence, we will ask one big question: how do we build the Cloud Native foundations to power the AI Era?

Our editorial Manifesto will be serve as a readmap.

We’ll follow a strong focus on large-scale corporations, multinational organizations and industry leaders to address technical depth,  share cutting-edge innovations and real use cases.

Our Editorial Manifesto has been crafted for Practitioners and scope the whole discussion.

To ensure every session meets the highest technical standards, our agenda is strictly vendor-neutral and carefully curated by Chris Mazur, AAIF & CNCF Ambassador and original founder of the Cloud Native Summit, and Mehdi Medjaoui, Apidays CEO.

To explore this, we are looking for talks across our three core tracks:

Our audience is made of Platform or Infrastructure Engineer, DevOps/SRE, Network or Software Architect, AI & Application Developer, Security Professional, mostly senior working in large-scale organizations.

So, if you are working on the convergence of cloud-native foundations and the AI imperative, we want you on board!

Critical dates to keep in mind:

Looking forward to hearing from you!

Community Spotlight

Yuri Shelke is an engineering leader at Capital One with extensive experience in APIs, integration, and enterprise platforms. His work covers specifications originally written for developers but now consumed directly by AI agents and automated tools.

Many organizations already publish OpenAPI specifications, but the quality of those specifications varies. Some contain incomplete schemas, outdated examples, inconsistent field names, or generic error responses. Human developers can often work around these issues by reading additional documentation, testing requests, or asking questions during implementation. Agents that consume APIs via OpenAPI-driven tooling rely more heavily on the information in the specification. Missing or inconsistent details can lead an agent to select the wrong operation, construct an invalid request, or mishandle an error.

Research on agent-driven API use shows that specification quality can materially affect performance. Studies of thousands of API endpoints have linked agent failures to missing parameters, inconsistent schemas, unclear descriptions, and other problems in OpenAPI contracts. In one study, correcting relatively small specification errors increased the success rate of automated API calls from 76.5% to 99.9%.

This makes maintaining the API contract very important. Schemas should reflect the deployed implementation. Descriptions and examples should stay current, and error responses should provide enough information for a caller to understand what went wrong. Keeping specifications synchronized with deployed services improves the chances that both developers and automated systems can use an API consistently.

A well-managed OpenAPI specification can also serve as a common contract across an organization. Maintaining separate descriptions of the same API for developers, applications, and AI systems creates additional opportunities for the documentation to drift out of sync. A complete and regularly updated specification gives each of these consumers a shared description of available operations, parameters, inputs, outputs, and expected behavior.

The same discipline can improve API governance. Teams can test specifications for missing fields, inconsistent schemas, undocumented behavior, and other problems before an API reaches production. As APIs evolve through new versions and integrations, these checks help reduce differences between documented and deployed behavior.

Shelke’s broader argument is that organizations do not need a separate API layer designed specifically for AI agents. They need to make the API contracts they already have accurate enough for machines to interpret reliably. As agents become another class of API consumer, the quality of the OpenAPI specification determines how well existing enterprise APIs can participate in automated workflows.

API Feed

Big Story

Modern API workflows rarely fail at a clean boundary. A single business transaction may pass through several services, databases, queues, and event streams before it is complete. By the time one component fails, several earlier steps may already have succeeded. A payment may have cleared, inventory may have been updated, and an event may have been published even though a later notification or downstream API call did not complete.

That creates a recovery problem. Restarting the entire workflow from the beginning can repeat operations that have already succeeded. In a simple workflow, the result may only be unnecessary API traffic. In a transactional system, it can mean duplicate charges, repeated orders, conflicting updates, or multiple events representing the same action. Recovery therefore has to preserve what has already happened while finding a safe way to continue what remains.

The problem becomes more significant during longer outages. Nordic APIs tracked reliability across more than 215 services between October 2025 and February 2026, covering cloud infrastructure, AI platforms, developer tools, payments, and other categories. The median incident resolution time was about 90 minutes, and most incidents were resolved within two hours. A smaller number of multi-hour and multi-day incidents, however, accounted for a disproportionate share of operational impact. During those longer disruptions, dependent systems may continue retrying failed calls or leave workflows partially completed for extended periods.

Production incidents show why simply retrying a failed request is not enough. On February 19, 2026, the authentication platform Clerk experienced a major outage after an automatic PostgreSQL ANALYZE generated an inefficient query plan, degrading database performance. During the incident, engineers also identified a customer using an overly aggressive retry mechanism that generated an unusual traffic spike. The retries did not cause the outage, but they added traffic and initially complicated diagnosis while the underlying database problem was still being investigated.

Cloudflare documented a related problem during its September 2025 Dashboard and API outage. A Dashboard bug repeatedly generated unnecessary calls to an internal Tenant Service API, while failed requests also triggered retries. During recovery, many clients attempted to reauthenticate at roughly the same time, creating a thundering-herd effect that again overloaded the service. Cloudflare later added randomized retry delays to spread recovery traffic over time.

These incidents highlight two separate recovery problems. The first is how often a failed request should be retried. The second is how a longer-running workflow should continue after part of it has already completed.

Retry controls address the first problem. Exponential backoff increases the delay between failed attempts, while jitter adds randomness so large numbers of clients do not retry at the same moment. Retry limits stop requests from continuing indefinitely. Together, these controls reduce the risk that recovery traffic adds enough load to prolong an outage.

Durable workflow systems address the second problem by recording execution state and preserving completed work. Different platforms implement this in different ways. AWS Step Functions can redrive a failed execution without rerunning steps that already completed successfully. Replay-based systems such as Temporal rebuild workflow state from recorded execution history and reuse the results of previously completed work. 

Idempotency provides another safeguard. An idempotency key allows an API to recognize that repeated requests represent the same logical operation and return the result of the first request instead of performing the action twice. This is particularly important when a caller experiences a timeout and cannot tell whether the original request succeeded. Without idempotency, retrying a payment, order creation, or inventory update can create a second side effect even though the first request was processed correctly.

These mechanisms work best together. Durable execution preserves workflow progress. Idempotency protects individual operations from duplication. Backoff and jitter control how retry traffic reaches downstream services. Retry limits prevent repeated failures from turning into endless request loops.

The broader shift is that recovery is moving closer to the center of API platform design. Event-driven systems, background jobs, and AI-enabled workflows continue long after the original request has returned. In that environment, reliability depends on more than whether an API comes back online. Platforms also need to know what work has already been completed, what can be safely retried, and how an interrupted workflow should continue once the failed dependency recovers.

Resources & Events

apidays Toronto brings together API architects, platform engineers, developers, and enterprise technology leaders for two days focused on building APIs for AI agents. The 2026 program, themed around the execution layer for the agentic era, covers API monetization, security, AI-driven automation, governance, and emerging technology trends across 100+ sessions. Speakers include senior leaders from Salesforce, Walmart, and Asana. Details →

apidays London brings together API architects, platform engineers, developers, and enterprise technology leaders for two days focused on agentic finance and embedded banking. The 2026 program, themed around the zero-click economy, explores the technical and regulatory architecture needed when the primary consumer of a bank's API is an autonomous agent, covering the shift from open banking data access to agent-executed transactions, as well as sessions on API monetization, security, governance, and AI-driven automation. Details →

You can find a list of all Apidays events here

Apply to speak at Apidays Singapore, NY, London, Paris, and more here

Hosted by the FIDO Alliance, Authenticate U.S. 2026 is the industry's flagship conference dedicated to digital identity and authentication. This year's theme, "New Frontiers," explores how identity systems are evolving beyond passkeys to support digital credentials, payments, and trusted AI agents. The agenda includes sessions on phishing-resistant authentication, API protection, workload and non-human identities, AI agent authentication, MCP, digital identity wallets, and emerging authentication standards. The conference brings together CISOs, identity architects, product leaders, and security practitioners to discuss the technologies shaping the next generation of identity infrastructure. Details →

Global CISO Insights 2026 is based on a survey of 306 CISOs and senior security executives across six countries, examining how enterprises are governing AI agents and non-human identities. The report finds that 81% of CISOs are concerned about excessive AI access, yet fewer than half are confident they can identify all AI agents in their environment (47%), control what those agents can access (46%), or authorize what individual agents are allowed to do (45%). It also highlights a leadership gap, with only 31% of CISOs reporting full alignment with their C-suite and board on acceptable AI risk. Read →

Insight of the Week

API Evangelist Kin Lane tested Stripe’s onboarding flow from an agent’s perspective and found that secret and restricted API keys still have to be created manually in the Stripe Dashboard. Stripe Connect can create connected accounts programmatically, but the credentials needed to use those accounts still require human intervention. The gap is relevant as companies build agents expected to discover services, authenticate, and act without stopping to set up dashboards.

For the Commute

As organizations adopt multi-agent AI systems, interoperability is becoming an important design consideration. In this session, Luiz Carneiro explores how two emerging open standards, Agent-to-Agent (A2A) and the Model Context Protocol (MCP), can work together in the same architecture. MCP provides standardized access to tools and data, while A2A enables independent agents to discover, communicate, and collaborate across different frameworks and models. Using a live multi-agent application, he shows how separating deterministic tools from agent-to-agent coordination can simplify system design, improve interoperability, and make it easier to build AI systems that combine specialized agents without tightly coupling them.

Stay tuned for bold ideas, fresh perspectives, and the next wave of API innovation

-The Apidays Team