Would be very useful to add a "Message History TTL" setting, allowing to define how long messages should remain in the channel history. For example, a channel could be configured to retain up to 1,000 messages, but only for 300 seconds. Messages would automatically expire after the configured TTL, even if the maximum history size has not yet been reached.

This would provide an additional layer of protection against unnecessary Redis memory growth and would be especially valuable for applications using transient data.

FA

Why:
RFC 10008 (published June 2026) standardizes QUERY as a safe, idempotent method that carries a request body — unlike GET, which isn't meant to carry one, and unlike POST, which isn't safe/idempotent/cacheable. Two concrete Xano use cases:

1. External API Request function: Some third-party APIs (search, filtering, data query providers) are starting to expose QUERY endpoints. The External API Request function currently only exposes a fixed set of methods (GET/POST/PUT/PATCH/DELETE); there's no way to send a request with method QUERY short of hoping a generic/custom-method override exists.

2. Custom endpoint definitions: For complex filter/search endpoints (e.g. dashboard queries against large Postgres-backed workspaces), POST is currently used as a workaround since GET can't carry a JSON filter body reliably across proxies/browsers. This misrepresents intent (POST implies mutation) and blocks correct HTTP caching. Native QUERY support would let these endpoints be marked safe/idempotent and cacheable, matching actual semantics.

Minimal implementation ask:

• Allow QUERY as a selectable method in External API Request.

• Allow QUERY as a method option when defining custom API endpoints (alongside GET/POST/etc.), with body support like POST.

• Respect Content-Type requirement per spec (reject if missing/inconsistent).

We're halfway through 2026, and we want to share what we've been building and where we're headed.

Software development is changing faster than ever. AI can generate code, spin up backends, and automate work that used to take teams weeks.

As AI writes more code across APIs, edge functions, databases, and services, the same business rules end up scattered across more places than any team can realistically govern. Building is getting faster. Understanding what AI built to trust what’s actually running is getting harder.

Frontends are becoming increasingly disposable. They're generated, iterated on, and replaced faster than ever. The backend is becoming the durable layer where business logic, integrations, and security rules live over time.

Xano is the backend development platform where teams build, govern, and scale the APIs that run their business. It centralizes business logic so developers and AI agents can build at AI speed while teams still understand, validate, and trust what reaches production.

This quarter, we made significant progress toward that vision.

What We Shipped in Q2

Q2 was one of the biggest quarters in Xano's history. We released v2.3 and v2.4, along with eight patches that strengthened the platform between major releases. Together, these updates focused on three areas: AI-assisted development, visual validation and governance, and observability. 

Want the highlight reel? Watch the v2.3 release overview covering the new Agent, navigation, CLI, and Sandbox all in one video.

AI-Assisted Development

Xano Agent

The Logic Assistant is now deprecated and replaced by the Xano Agent.

Instead of working within a single endpoint, the Agent can build, modify, and debug across your entire backend, including APIs, functions, tasks, triggers, middleware, and your database. It uses XanoScript and the Developer MCP under the hood, so every change maps directly to Xano's visual workflows. Before anything is published, you can review every step in the visual function stack your team already knows.

Every AI-generated change stays visible and reviewable before it reaches production.

Read the docs 

Xano CLI: General Availability

The CLI first shipped to Xano Insiders in late February and became generally available in April.

Developers can push and pull an entire Xano workspace as XanoScript, work from their preferred IDE, and integrate directly with existing Git workflows. AI coding tools like Claude Code, Cursor, Copilot, and Codex can work directly with Xano while every deployment still goes through RBAC enforcement and a full dry-run preview.

Alongside the CLI, we introduced Sandbox environments, which adds ephemeral environments as a safety layer. Developers can push changes into an isolated sandbox, review them visually, and promote them into a workspace branch only after validation. It provides a structured workflow for AI-assisted and code-first development while reducing deployment risk.

Read the docs or watch the intro.

Developer MCP

The Developer MCP gives AI coding agents the context they need to build in your Xano workspace from your local development environment. Agents can read, write, and validate backend logic through XanoScript while routing every change through the sandbox and deployment pipeline before it reaches production.

A new initialization skill also generates a workspace-specific playbook, giving AI agents the context they need to work safely inside your environment from day one.

Read the docs

XanoScript: General Availability

XanoScript is now generally available.

When AI generates your backend via the Xano Agent or external AI coding agents with the Developer MCP, it uses XanoScript. XanoScript maps AI-generated backend logic to Xano's visual builder. Developers and AI agents can work in code while every change remains understandable inside visual workflows. We are constantly working to improve XanoScript’s stability, and making it GA reflects that progress. 

New to XanoScript? Start with the key concepts.

Visual Validation and Governance

A Rebuilt Workspace Experience

v2.3 introduced the largest navigation update we've ever shipped.

Today, much of the building happens in IDEs and AI tools outside Xano. Our job is to make sure everything that comes back into your backend is understandable, governable, and ready for production.

The top navigation, sidebar, publishing flow, draft management, footer, and global search were redesigned around that workflow. Global search now lives in the header. Publishing operates at the workspace level. Connect Hub brings together everything you need to connect frontends and AI tools. Branch and datasource controls stay visible throughout the application, making it easier to understand exactly where you're working.

Read the docs

Live Agent Diff Review

Agent changes are now visible as they're generated.

Instead of waiting until the end of a session, developers can watch visual or XanoScript diffs update in real time. Database schema modifications receive explicit confirmation prompts, while live file trees and change counts make it easy to continue working with the Agent without losing visibility into what's changing.

Tenant Center Improvements

Enterprise customers received several infrastructure improvements during the quarter, including tenant snapshots, dramatically faster deployments, a no-transaction deployment option for high-traffic environments, expanded Metadata API support, and tighter permission controls throughout Tenant Center.

Read the docs

Production Monitoring & Observability

Error Logs Dashboard

v2.4 introduced a new workspace-wide Error Logs Dashboard.

Rather than searching object by object, teams can now see failures across APIs, functions, tasks, triggers, and middleware in one place. Errors are grouped by signature to reduce noise and tracked through New, Regression, Ignored, and Fixed states. One click takes you directly to the source statement, and paid plans can automatically trigger workflows based on matching error patterns.

Request History Dashboard

Request History Dashboard has grown from a widget into a dedicated monitoring experience. 

Six tabs now cover request history for every Xano primitive (APIs, Tasks, Triggers, etc), all in one place, with analytics for success rate, p95 duration, status distribution, HTTP methods, and traffic patterns. A 24-hour histogram helps isolate spikes, while cross-workspace user search makes it easier to trace activity across your backend.

Available on every plan.

Platform Reliability

Alongside these larger releases, we continued improving the platform itself.

Eight patches throughout the quarter improved XanoScript reliability, async execution, database stability, performance under load, and dozens of edge cases surfaced through error monitoring. 

What We're Working On

We're continuing to invest in making Xano the platform where teams can confidently build, govern, and operate the systems that power their business.

Here are a few areas we're especially excited about:

A Better AI Development Experience

We're continuing to invest in making AI workflows faster, more reliable, and more connected to the tools developers already use. The gap between a prompt and a production-ready backend should continue to shrink.

A Faster XanoScript Runtime

Significant engine improvements are underway to improve function stack performance, especially for demanding workloads.

A Workspace Knowledge Layer for Build Agents

Specifications, documentation, and business rules are becoming first-class parts of the platform. If AI agents are going to build correctly, they need more than schemas. They need the context behind your business.

Next-Generation Observability

The monitoring capabilities released in Q2 are only the beginning. We're building deeper live insights, smarter alerting, and tighter connections between observability and AI-assisted testing.

Hosting and Runtime Flexibility

We're exploring new ways for teams to build, host, and serve more of their applications within Xano while keeping business logic governed and portable across environments.

Some of this work is already underway. Some of it is longer-term. All of it supports the same goal of helping teams move faster without giving up trust, governance, or control.

Thank You

Everything we shipped in Q2 was shaped by feedback from this developer hub. The bugs you reported, the features you requested, and the workflows you shared all influenced these releases.

AI is changing how software gets built. The next challenge is making sure the business logic behind that software stays centralized, understandable, and trustworthy as it evolves.

We believe teams should be able to build at AI speed without giving up governance or control. That's what we're building Xano to do, and we're grateful you're building it with us.

More soon.

I'm building an audit log using a PRE-middleware that I want to slap onto every endpoint — authenticated or not. The function stack is dead simple: Add Record into log_audit with auth_id, uri, method, etc.

Works beautifully... right up until a public endpoint shows up without an auth object. No auth.id, middleware throws a tantrum, request dies. 💥

What I'm after: a clean, fast way to log the record and just leave auth_id empty when the endpoint is unauthenticated — instead of crashing.

A few things I'm wondering:

• What's the most reliable way to detect "no auth present" inside middleware without a try/catch wrestling match?

• Is there a tidy pattern to make auth_id optional/nullable in the Add Record step?

• Anyone running a global audit middleware across mixed public/private endpoints — how did you handle the auth gap?

Short version: I want one middleware to rule them all, and I'd rather it logged a quiet null than fell over. Curious how others solved this.

Thanks! 🙏

Our application relies heavily on fetching real-time data packets from an external engine. The payload returned from this third-party API is massive, nested JSON, and highly unoptimized. Currently, when a user logs in, Xano hits the external API, receives the raw payload, loops through the data to transform it into a clean format, and then passes it to the frontend.

As our daily active user count climbs, this setup is causing two major issues: we are flirting with the external API's rate limits, and the time-to-first-byte (TTFB) is too high due to the heavy data transformation happening inside the Xano function stack on every request.

I want to redesign this workflow using Xano’s internal features:

• Setting up a Cron Job / Background Task that pings the external API once every night at midnight UTC to grab the global data packet.

• Using Xano's data manipulation tools to instantly parse, clean, and store that structured data into a local Xano table.

• Implementing a conditional caching layer so that when a user requests their dashboard, Xano checks our local, optimized table first before ever considering an external API call.

Has anyone implemented a similar server-side caching and data-syncing routine for an external provider? Are there any hidden gotchas regarding memory execution limits during heavy JSON parsing inside background tasks that I should watch out for? Appreciate any advice or snippets you can share!

I have an agent built in Xano, which has access to multiple tools and can require multiple loops. I’ve got the main process set as a background task which works great, but seems to still be hitting a timeout issue after 300s.

Surely background tasks need to be able to run for extended periods? It’s multiple API calls, so it’s not even that a single call is hitting the 300s runtime mark.

If there’s documentation or someone can help I’d be super appreciative!

For larger projects with many tables, it's common to have dozens of triggers (for example, audit logging), and the trigger list can become difficult to navigate. Being able to create folders/groups and place multiple triggers inside them would make organization and maintenance much easier.

Thanks for considering this feature!

I would like to suggest an idea

the same as there is a option for testing to search and select a auth token so we can run a test

it would be a very nice feature to add a input box as a JSON field to add content to mock the auth.extras for testing purposes

because if we have some items in a function stack which are dependent on information from the auth.extras we should be able to enter it for testing

thank you

To reproduce, create an environment variable named "testenv" and then create a function "test_env" that contains an object variable (e.g. {}) where one of the object's values references the "testenv" environment variable:

function test_env {
  input {
  }

  stack {
    var $x1 {
      value = {}|set:"key":$env.testenv
    }
  }

  response = $x1
}

After saving the function, if you navigate to the "Keys & Variables" section and inspect the "testenv" variable, the "Referenced By" does not show the function as a consumer of that environment variable, even though it is clearly being used within the object:

However, if within the same function a separate variable is created and assigned directly to "testenv" (outside of the object structure), the "Referenced By" section immediately detects the function correctly and lists it as a reference:

function test_env {
  input {
  }

  stack {
    var $x1 {
      value = $env.testenv
    }
  }

  response = $x1
}

This suggests that the reference tracking mechanism may not be detecting environment variables when they are used inside object definitions.

FA

In XANO:

1 - Created an endpoint that I added a backslash to the name “/” (rookie mistake)

2 - The endpoint was created with two backslashes as I should NOT have added one to the name. "//"For example “//category/tree” (did not know Xano generate a backslash by default)

3 - I tried to correct in XanoScript - as I could not find an easier "rename" option.

4 - After trial and error - I deleted it. And It no longer exists in the API list.

5 - But I can’t create a new one because it says "The name conflicts with another API endpoint."

I am guessing it’s some sort of cache issue. But being very much a novice - I have no idea where to look or IF that is the issue.

These are currently the category API:
category (5)

GET category
POST category
DELETE category/{category_id}
GET category/{category_id}
PATCH category/{category_id}

Any help or suggestions would be welcome! Thank you!