I’m vita from the Tokatlas team. We’re a commercial multi-model API platform, and we’re running a 20-spot free API-credit trial for developers with real projects. The 20 spots are shared across our community outreach, not 20 per site.

For Xano builders, I’d love to hear about one specific backend task: extracting fields from a document, generating a draft, or an agent making several model calls. Tell us what goes in, what a useful result looks like, and which model or API features you need. A short description is plenty.

We’ll select a mix of suitable use cases and confirm the model, endpoint, credit scope and expiry before you start. This is an invitation to test your workflow, rather than a prebuilt Xano template. Please keep API keys, customer data and private code out of the comments.

To join, reply here or email affiliates@tokatlas.com with “Xano trial” and a few lines about your project. Replies close November 2, 2026, at 15:59 UTC; we’ll share selected usernames and next steps here within three days. No purchase, upvote or positive review required.

Take a look: https://app.tokatlas.com

What would you put through its paces first?

is there anyone having issues on user's table, in this case, missing the email and sometimes other info? i mean, the email field is going to null with no reason

I've contacted support, but no feedback yet. This is impactating my application, and i wonder if someone has the same problem

Thanks

A couple of times already I have nearly committed a table definition that includes pulled records in the items[] array.

Is there a recommended approach for avoiding this? Or can we have data in separate files so it can be included in gitignore?

Although creating a separate Realtime server has been suggested as a workaround, this does not fully solve the problem, since the server still executes against the live branch. Its underlying functions and handlers must therefore also exist in production, breaking branch isolation and forcing developers to maintain duplicated servers, functions, and handlers just to test changes safely.

Ideally, Realtime V2 should allow clients to connect directly to a specific branch, following the same principle already available for API requests. For example, if an API request can target a specific branch (eg: "branch2") using https://host/api:can:branch2/endpoint, a similar mechanism could be supported for websocket connections, such as wss://host/ws/can:branch2.

In addition to specifying the branch, it should also be possible to specify the Data Source for the connection using an x-data-source parameter, allowing developers to select both the branch and the Data Source independently. For example: wss://host/ws/can:branch2?x-data-source=test.

This would provide full control over the execution environment, allowing developers to test Realtime functionality against the appropriate branch and Data Source without affecting production data or logic.

This capability would make Realtime V2 more consistent with the existing Xano development workflow, eliminate the need for production-based workarounds, and significantly improve the safety and efficiency of Realtime development.

FA

At the end of Q2, we talked about how quickly AI is changing software development. Three months later, that shift is only accelerating.

It has never been easier to build software. AI can generate an application, write an API, and connect a database in minutes. Building is quickly becoming a commodity. Soon there will be more code than anyone can review line by line.

But building the first version is only the beginning.

The harder questions come as the software starts to matter and more people work on it. How do you understand what AI built? How do several people and agents work on it under the same rules? And how do you move it into production, next to the systems you already run?

Most platforms answer with parts. A database here, a runtime there, and the assembly is left to you.

Xano takes the other path. It is one platform to build, run and govern AI-built software, and our job is to make the hard decisions for you: how changes get reviewed, and how they reach production. You keep building fast. Your whole team can understand what was built and trust it.

That is where we're putting our focus: getting what you build into production, and keeping it trusted once it's there.

In Q3, we made some of our biggest progress yet toward that vision.

From AI-assisted building to a shared way of building

AI agents are becoming part of the development team. But giving everyone an AI coding tool doesn't automatically mean they're building the same way.

With Xano Knowledge, teams can now define the rules, documentation, and repeatable skills they want agents to follow once, and ensure that context is used by everyone.

Your workspace can carry persistent instructions through AGENTS.md, refer to documentation that agents can pull in when needed, and Skills that define how your team performs specific tasks. That same context works with the Xano Agent and with external coding agents through the CLI and Developer MCP.

More importantly, that knowledge belongs to the workspace, not an individual developer's laptop or AI session. It can be reviewed, versioned, and controlled by admins just like the rest of your application.

As more software is built by agents, we think this becomes increasingly important: the way your team builds should belong to your team.

A more complete development lifecycle

We also continued expanding where and how developers can work with Xano.

In Q2, the CLI and Developer MCP opened Xano to external development workflows. In Q3, we extended that workflow to more of the application.

With Static Frontend Hosting through the CLI and MCP, developers and agents can pull, push, and deploy static frontends alongside their backend, making it possible to work across more of an application from tools like Claude Code and Cursor without breaking the Xano development and deployment flow.

We also expanded Sandbox environments so developers and AI agents can create temporary environments across multiple branches and work in parallel without interfering with each other. Changes can be built and tested in isolation before they move forward.

The direction here is simple: the faster software gets created, the more important it becomes to give every change a safe place to exist before it reaches production.

Modernize without starting over

Not every application starts from scratch.

Some of the most important software our customers run today has been built over years, across different languages, services, vendors, and architectures. Replacing all of it rarely makes sense.

With Microservices, teams can now bring existing Docker containers and Helm charts into Xano and call them directly from the Xano function stack. Those services can be monitored from the workspace and included in releases alongside the rest of the Xano application.

That means adopting Xano doesn't have to start with a rewrite.

A team can keep the services that already work, build new APIs and business logic around them, and modernize incrementally. Existing and new software can move through the same release process instead of creating another disconnected stack to operate.

That matters because a platform for AI-built software can't only work for what AI creates tomorrow. It also has to work with the systems your business depends on today.

More control over what reaches production

We made significant progress this quarter on the other side of building: running software in production.

Realtime v2 brings more of the Xano development lifecycle to realtime applications, including authentication and authorization logic, payload validation, branches, Sandbox review, version history, RBAC, Request History, debugging, and rollback.

Teams can now treat realtime logic much more like the rest of their backend instead of operating it as a separate system.

Testing also became easier to understand and act on. Test results now persist, run states are clearer, failures explain more about what went wrong, and the Agent can help create and debug tests.

And underneath all of this, we re-platformed Xano's request execution engine to deliver lower latency, more throughput per instance, and steadier performance under load without requiring customers to change their applications.

These aren't isolated improvements. They're part of the same idea: building quickly only matters if teams can build together, and confidently run what they build.

Build with the AI infrastructure your team chooses

The AI ecosystem is moving too quickly for teams to be locked into a single model or provider.

In Q3, we expanded AI provider support to include OpenRouter, AWS Bedrock, LiteLLM, and Azure Foundry, giving teams more flexibility to use approved models and existing AI infrastructure with Xano Agent and Agents.

For individual developers, model choice is often a preference. For teams, it can also be a question of security, cost, infrastructure, and organizational policy.

Xano should fit into those decisions rather than force teams around them.

The bigger picture

Stepping back, the most important thing about Q3 isn't any single feature.

It's how the pieces work together.

A developer or AI agent can build in the tools they prefer. The team's knowledge and standards can follow them. Multiple builders can work safely in isolated environments. Existing services can become part of the application instead of being rewritten. Tests help validate what changed. Releases create a deliberate path into production. And once software is running, Xano gives the team a shared place to understand and operate it.

That is increasingly what we believe teams need from a backend platform in an AI-first development world.

The ability to generate software will continue getting cheaper and faster. The difficult part will be turning what gets generated into software a team can understand, operate, and confidently put in front of customers.

That's the problem we're building Xano to solve.

Thank you to everyone who built with us, tested these releases, reported issues, and pushed us throughout Q3. Your feedback continues to shape where the platform goes next.

We're excited about what these pieces make possible.

More soon. 🚀

Prakash

It catches things a format check passes, for example 020 7946 0958, a valid-looking UK number from Ofcom's range set aside for drama, or NANPA's 555-0100 to 555-0199 fictitious numbers.

You can try three checks a day on the homepage with no account, and signing up gives you 500 credits. A lookup that establishes no evidence costs nothing; a partial one can be charged.

API docs: https://orisift.com/x?m=post&c=xano-showcase&to=%2Fdocs

I built Orisift. Feedback from anyone running signups in Xano would help.

check password sometimes returns false for users with the correct password, for a few minutes up to an hour, then works again on its own.

- Only accounts with old hashes (created years ago and carried over to our current workspace) are affected.
- Once the password is saved again (new hash), we've never seen it fail.
- Not a code or connection issue. Upgrading the instance didn't help.

About 99% of our users still have old hashes, so this hits almost everyone.

Has anyone seen this? Is there a way to re-hash existing passwords without asking every user to reset?

This has been a headache for us for weeks now, so any pointers would be really appreciated. Thanks!

The main goal was to harden the usual OAuth flow against login-CSRF by adding:

• a 256-bit browser nonce stored in sessionStorage

• signed OAuth state generated by Xano

• provider binding

• 10-minute expiry

• nonce hashing

• verification before the authorization code is exchanged

I tested the flow end to end against both Google and LinkedIn, including:

• wrong nonce

• tampered state

• missing state / nonce

• cross-provider state

• expired state

• replayed authorization codes

The repo includes:

• Xano functions and endpoints

• frontend JavaScript examples

• setup instructions

• architecture diagrams

• threat model

• runtime test cases

GitHub:
https://github.com/jperaleselizondo-hash/secure-xano-oauth

It’s intended as a reference implementation, not an official Xano solution. If anyone here is building custom OAuth flows in Xano, I’d be interested in feedback, edge cases, or improvements.

I'm building a WeWeb front-end on top of Xano, and I'm still fairly new to this side of things, so apologies if I'm missing something obvious.

While profiling our page loads, I noticed that every authenticated API call is preceded by a CORS preflight (OPTIONS request), even for URLs that were just called. To make sure, I ran a clean test: browser cache enabled, navigating page A → page B → page A within 20 seconds. On the second visit to page A, every call was preflighted again for the exact same URL. One endpoint was preflighted three times in 15 seconds. It also happens for a direct XHR POST that doesn't go through WeWeb's service worker.

Each preflight adds roughly 40–80 ms before the actual request (more when the server is busy), and since our calls run one after another, it adds up on every page.

The default preflight response we get looks like this:

Access-Control-Allow-Origin: <echoed origin>

Access-Control-Allow-Headers: *

Access-Control-Max-Age: 86400

Access-Control-Allow-Credentials: true

From what I've read, "*" in Access-Control-Allow-Headers doesn't cover the Authorization header, so browsers accept the preflight but don't reuse it from cache (https://github.com/whatwg/fetch/issues/1278). That would explain what we see, but I may be wrong about the cause.

I tried Custom mode on one API group (Allow-Headers set to "Authorization" and "*"), and ran into two things:

- an origin of "*" seems to be matched literally, so our real origins were rejected (I reverted right away);

- the preflight seems to be answered by the live branch, since OPTIONS requests don't carry the X-Branch header, so changing the setting on a dev branch has no effect on preflights.

So my questions:

1. Has anyone else noticed this? Is it expected with the default CORS configuration?

2. Is there a recommended way to get preflights cached for authenticated requests, without listing every origin on every API group and branch? For example, could Authorization be added to the default Allow-Headers, or could Custom mode reflect the request origin the way Default does?

Thanks a lot for any pointers!