Recent Announcements

Fri, May 29

New in 2.4: Xano Agent UX Improvements—One-Step Visual Diff Review

We've significantly upgraded the review experience inside Xano Agent. Previously, reviewing what the agent built meant leaving the conversation, stepping into a separate modal, and stepping back to keep iterating—a workflow that broke flow state. Now, every change the agent makes is reviewable visually, inline, right alongside the agent chat. Here's what changed: Visual diff for all object types: Database schema changes render in the familiar dbo-overview, toolset and agent changes render in the toolset schema view, and function/query/task changes render in both the function stack and visual canvas. Raw XanoScript with full diff details is still available behind a toggle. Inline review alongside the agent: A persistent file tree on the left lets you browse the workspace ("All files" mode) or jump to only what the agent changed ("Changes" mode, with a modification count badge). The middle pane is the diff viewer; the right pane is the agent chat. All three are visible and resizable at the same time. Diff / Now toggle: See the proposed change against current state or edit the current file directly—without losing the diff context. Real-time updates: As the agent modifies files, the file tree, change counts, and "Push to Draft" button update live without interrupting your conversation. Keep prompting while reviewing. Database change safeguards: Schema changes that publish immediately are clearly flagged with a warning and require explicit confirmation on ‘Push to Drafts’. Publish stepper: Distinguishes "Push to draft" (safely testable) from "Required publish" (immediate) so you always know which changes need extra care. Now you can prompt, watch, and review in one continuous motion—and every object type has a visual review surface so you can understand changes at a glance without looking at the XanoScript. Try it out by clicking the Xano Agent button in your workspace sidebar, and let us know what you think.
Fri, May 29

New in 2.4: Error Logs Dashboard with Version Tracking, Triggers, and Urgency Scoring

Error Logs, introduced in 2.3 inside per-object side panels, now has a full workspace-wide Monitoring dashboard. Errors are automatically grouped by signature, scored for urgency, and tracked through a complete lifecycle—turning hundreds of raw log lines into a single triageable entry per real bug. Here's what's new: "Open in Stack": One-click navigation from any error directly into the source function stack so you can fix it in place. No third-party error tool can do this. "Configure Trigger": One-click automation that wires any error into a new or existing On Error Trigger — alert a Slack channel, page on-call, retry with backoff, or route to a fallback. (Paid plans only.) Grouped error signatures: A single recurring bug shows up as one entry with a count and hourly sparklines, not 500 individual log lines. Aggregated across APIs, Functions, Tasks, Middleware, and Triggers. Lifecycle status tracking: Every error signature is tracked as New, Regression, Ignored, or Fixed. A previously-fixed error that reappears is automatically flagged as a regression. Version tracking: Know which version introduced the error and view the diff of that version. Urgency scoring: Low / Medium / High / Critical tiers based on occurrence frequency and baseline statistics so the most impactful issues surface first. Per-signature detail page: Error histogram, callers visualization (Sankey diagram and call tree), baseline statistics comparison, common payload analysis, version tracking, and stack-level recommendations. Before this release, finding error patterns meant opening each API, function, task, middleware, and trigger one at a time. Now you can detect a regression, jump straight to the relevant statement, and wire up an automated response—all without leaving Xano. The dashboard and Open in Stack are available on every plan. Error Triggers automation requires a paid plan. Try it out under Monitoring → Error Logs.
Fri, May 29

New in 2.4: Request History Dashboard for Full-Stack Observability

Request History now has a real home. It is elevated from a widget on the home Dashboard (limited to APIs) to a dedicated top-level Monitoring page with the analytical depth you'd expect from a standalone observability tool—and it covers every Xano primitive, not just APIs. With the Request History Dashboard, you get: Every primitive in one place: APIs, Functions, Tasks, Middleware, Triggers, and Tools—switchable via tabs without navigating away. Interactive 24-hour histogram: Click and drag to zoom into a traffic spike or quiet period directly on the chart. Summary analytics on every tab: Success rate %, p95 duration, and donut breakdowns of method mix (GET/POST/etc.), status distribution (2xx/3xx/4xx/5xx), and result distribution. Filter by user across primitives: See the full activity of any authenticated user across your entire workspace in one view. Tab-specific filters: Method, status, IP, authenticated user, and API group for APIs; runtime and caller for Functions; frequency and status for Tasks; target wraps for Middleware; action type, table, and datasource for Triggers; status for Tools. Search, sort, and paginate: Search by URL or name depending on the tab, and sort by Time or Duration. Full click-through detail panel: Headers, payload, response body, and execution details—the same depth previously only reachable through per-object side panels or for APIs from the Dashboard. Before this, seeing workspace-wide traffic meant hopping between individual objects. The per-object side panels still work for in-context debugging when you're already inside an object. The new dashboard is where you go for cross-workspace operations and analysis. Check it out under the Monitoring tab in your workspace, and let us know what you think.
Mon, Apr 20

New in 2.3: Performance Insights in Function Stack

Performance Insights now surfaces execution time for each individual statement directly inline in the function stack—visible on hover, without leaving the editor. You can toggle the inline metric on or off per-user in Workspace Settings. Error snapshots captured by Error Logs can also be opened directly in the stack, giving you a continuous path from spotting an error to investigating the performance of the logic around it. Workspace-level Performance Insights already showed which endpoints are slow—but pinpointing the specific statement responsible meant cross-referencing timing data outside the editor. Bringing execution timing inline closes that loop so you can see exactly where time is being spent at the statement level, right where you're already reading and editing logic. Our updated Performance Insights documentation is here in case you want to learn more.
Mon, Apr 20

New in 2.3: Error Logs for Better Observability

Error Logs is a new observability feature that captures errors across all Xano stacks—API endpoints, tasks, functions, and triggers—and surfaces them in an aggregated, actionable view directly inside the product. With Error Logs, you get: Grouped errors: Repeated occurrences of the same error are tracked together by signature rather than flooding your view. Occurrence count and timestamps: Get the details you need for each error. The ability to mark errors as fixed or ignored: Useful for distinguishing real regressions from expected user input errors. Full stack state snapshot: When you open an error, Xano loads the exact inputs, execution path, and point of failure at the moment it occurred. 30-day retention: Error snapshots are available for 30 days. Before Error Logs, finding a production error meant manually combing through Request History with no aggregation, no grouping, and no way to know if an error happened once or a thousand times. Now you can see what's breaking, how often, and exactly what the stack looked like when it did.

Latest Posts

  • Where to install extensions? I can't find marketplace

    I think I'm going crazy cause I really can't find xano marketplace. I'm planning to install auth extensions for google, facebook etc. The video tutorials and links are outdated? https://www.xano.com/connect/facebook-oauth/ https://www.xano.com/connect This is all I could find but there's no way to install? Please help. Thank you.
    1
    2
    Thu, Jun 11

  • Working from IDE

    I'm trying to pull my workspace to my IDE, but it can't pull custom functions. I've used the vscode extension, and the xano cli but it's not letting me pull the functions nor export it.
    0
    1
    Mon, Jun 8

  • How to sort a field in a nested addon

    Hi, I am trying to sort a field in a nested addon - as below I want to sort this by event_sequence. I have watched the video here. This is my function - Xanoscript - query getOrderDetails_0 verb=GET { api_group = "shipogogo" input { int order_id? } stack { db.query sgogoOrders { where = $db.sgogoOrders.id == $input.order_id return = {type: "list"} addon = [ { name : "orders_to_shipments" input: {sgogoorders_id: $output.id} addon: [ { name : "shipments_to_events" input: {sgogoshipments_id: $output.id} as : "_shipments_to_events" } { name : "shipments_to_couriers" input: {sgogoCouriers_id: $output.sgogocouriers_id} as : "_shipments_to_couriers" } ] as : "_orders_to_shipments" } ] } as $sgogoOrders1 var $sort_sequence { value = $sgogoOrders1 |set:$sgogoOrders1._orders_to_shipments._shipments_to_events:"$$|sort:event_sequence" } } response = $sgogoOrders1 } and here is the error I also tried a sort - query getOrderDetails_0 verb=GET { api_group = "shipogogo" input { int order_id? } stack { db.query sgogoOrders { where = $db.sgogoOrders.id == $input.order_id return = {type: "list"} addon = [ { name : "orders_to_shipments" input: {sgogoorders_id: $output.id} addon: [ { name : "shipments_to_events" input: {sgogoshipments_id: $output.id} as : "_shipments_to_events" } { name : "shipments_to_couriers" input: {sgogoCouriers_id: $output.sgogocouriers_id} as : "_shipments_to_couriers" } ] as : "_orders_to_shipments" } ] } as $sgogoOrders1 !var $sort_sequence { value = $sgogoOrders1 |set:$sgogoOrders1._orders_to_shipments._shipments_to_events:"$$|sort:event_sequence" } var $sort_sequence { value = $sgogoOrders1 |sort:$sgogoOrders1._orders_to_shipments._shipments_to_events.event_sequence:"itext":true } } response = $sgogoOrders1 } but got this error - I would appreciate any assistance. Thanks Steve
    0
    2
    Mon, Jun 8

Recent Activity

  • Haira Dar
    ·Posted in Get Help

    Where to install extensions? I can't find marketplace

    I think I'm going crazy cause I really can't find xano marketplace. I'm planning to install auth extensions for google, facebook etc. The video tutorials and links are outdated? https://www.xano.com/connect/facebook-oauth/ https://www.xano.com/connect This is all I could find but there's no way to install? Please help. Thank you.
    1
    2
    Thu, Jun 11
    Help! I'm a Noob
    Answered
  • Anthony Naui
    ·Posted in Get Help

    Working from IDE

    I'm trying to pull my workspace to my IDE, but it can't pull custom functions. I've used the vscode extension, and the xano cli but it's not letting me pull the functions nor export it.
    0
    1
    Mon, Jun 8
    Connect Xano to ..
  • Steve Carter
    ·Posted in Get Help

    How to sort a field in a nested addon

    Hi, I am trying to sort a field in a nested addon - as below I want to sort this by event_sequence. I have watched the video here. This is my function - Xanoscript - query getOrderDetails_0 verb=GET { api_group = "shipogogo" input { int order_id? } stack { db.query sgogoOrders { where = $db.sgogoOrders.id == $input.order_id return = {type: "list"} addon = [ { name : "orders_to_shipments" input: {sgogoorders_id: $output.id} addon: [ { name : "shipments_to_events" input: {sgogoshipments_id: $output.id} as : "_shipments_to_events" } { name : "shipments_to_couriers" input: {sgogoCouriers_id: $output.sgogocouriers_id} as : "_shipments_to_couriers" } ] as : "_orders_to_shipments" } ] } as $sgogoOrders1 var $sort_sequence { value = $sgogoOrders1 |set:$sgogoOrders1._orders_to_shipments._shipments_to_events:"$$|sort:event_sequence" } } response = $sgogoOrders1 } and here is the error I also tried a sort - query getOrderDetails_0 verb=GET { api_group = "shipogogo" input { int order_id? } stack { db.query sgogoOrders { where = $db.sgogoOrders.id == $input.order_id return = {type: "list"} addon = [ { name : "orders_to_shipments" input: {sgogoorders_id: $output.id} addon: [ { name : "shipments_to_events" input: {sgogoshipments_id: $output.id} as : "_shipments_to_events" } { name : "shipments_to_couriers" input: {sgogoCouriers_id: $output.sgogocouriers_id} as : "_shipments_to_couriers" } ] as : "_orders_to_shipments" } ] } as $sgogoOrders1 !var $sort_sequence { value = $sgogoOrders1 |set:$sgogoOrders1._orders_to_shipments._shipments_to_events:"$$|sort:event_sequence" } var $sort_sequence { value = $sgogoOrders1 |sort:$sgogoOrders1._orders_to_shipments._shipments_to_events.event_sequence:"itext":true } } response = $sgogoOrders1 } but got this error - I would appreciate any assistance. Thanks Steve
    0
    2
    Mon, Jun 8
    Working with APIs

Latest Feature Requests

  • 0
    Mihály Tóth

    'Export Data' feature to pick the workspace live branch

    This screen in the settings allows the export of the workspace including data and business logic in the 'workspace.json' file. This export always exports from the workspace v1 branch, but in several cases the live branch of a workspace has been moved off from the v1 and as a result by exporting from here, we get to a 'business logic drift' state. I completely understand that to export the latest business logic with option to control the exported branch we can use the metadata API route: 'workspace/export-schema' and the 'workspace/export' endpoints, which allow specifying the branch. But it would be nice to not have to use the metadata API for something that's also there in the UI.
  • 0
    Louis Machado

    Option to disable or suppress the Set-Cookie: XNS header on API responses

    Problem Statement Xano automatically appends a Set-Cookie: XNS=...; Path=/socket/; Secure; HttpOnly; SameSite=Strict header to every API response — including read-only, public endpoints with no authentication or Realtime features enabled. This header cannot be removed using Xano's built-in HTTP Header function step, as it is injected at the infrastructure level after the function stack runs. This causes a critical caching problem: most CDNs (e.g., Cloudflare, Fastly, AWS CloudFront) will not cache any response that contains a Set-Cookie header, since cookies are typically user-specific. As a result, even endpoints with response caching enabled in Xano cannot benefit from CDN-level caching. This defeats the purpose of using a CDN and puts unnecessary load on the Xano instance for every request. Proposed Solution Please provide one or more of the following options: A workspace-level toggle to disable the XNS cookie on workspaces that do not use the Realtime feature. 2. A way to suppress or strip the Set-Cookie header on specific API endpoints via the HTTP Header function step. 3. At minimum, official documentation clarifying whether this behavior is intentional or a bug, so users can plan their infrastructure accordingly.
  • 0

    Request History: Include Seconds in Timestamps and Show Timestamp in Request Detail View

    Currently, each request in the list shows the method, status, path, and a timestamp — but the timestamp is only displayed up to the minute. In practice, this makes it quite difficult to distinguish between multiple requests that happen within the same minute, especially when debugging high-frequency endpoints or rate limiting scenarios. Proposed Improvements 1) Include seconds in the timestamp (at minimum) Ideally, timestamps should include seconds (and even milliseconds, if possible), for example: 27/03/2026 17:25:32 instead of just 17:25. This would make it much easier to trace request sequences and understand timing-related issues. 2) Show the timestamp inside the request detail view Timestamp is only visible in the request list. Once you open a specific request, that information is no longer shown. It would be very helpful to also display the exact timestamp inside the request detail view, so that when inspecting a single request, you still have full context about when it occurred. FA
  • 0

    Native Scheduling to Post Process for Precise Background Execution

    I’d like to propose a feature that, in my opinion, would significantly improve Xano’s capabilities around background processing and bring it more in line with modern, event-driven architectures. Right now, Xano gives us two useful mechanisms: Post Process, which allows functions to run immediately after an endpoint response (great for async/non-blocking flows) Background Tasks, which allow recurring jobs However, there is a clear gap: there is no native way to schedule a function to run at a specific point in time (i.e., no scheduler). This has been mentioned in community posts going back 2–4 years, and while there are workarounds, they are far from ideal. The typical approach involves creating a database “queue” table, running a recurring background task to poll that table, executing pending jobs. This approach feels quite outdated (it honestly reminds me of old PHP + cronjob patterns) and comes with several drawbacks: Inefficient at scale (constant polling + DB reads) Bulk/spiky execution patterns instead of smooth distribution over time Lack of timing precision (execution depends on task intervals, not exact timestamps) Additional complexity and maintenance (tables, polling logic, cleanup, retries, etc.) Unnecessary resource usage, especially on the database layer Proposed Solution Instead of introducing a completely new system, my suggestion is to extend the existing “Post Process” feature. Specifically, allow an optional field such as a “timestamp” (or scheduled_at) to be defined in Post Process. If no timestamp is provided → behavior remains the same (execute immediately after response) If a timestamp is provided → execution is deferred and triggered exactly at that time Under the hood, this would rely on an internal Xano-managed queue, removing the need for developers to build and maintain their own scheduling systems. Benefits Precise scheduling (execution at a specific timestamp, not “best effort” intervals) Better scalability (no polling, no bulk spikes) Lower resource usage (no DB queue required) Cleaner architecture (no custom schedulers, simpler backend logic) More modern paradigm (event-driven, async-first design) This would effectively turn Post Process into a more powerful async orchestration tool, covering both immediate background execution and delayed/scheduled execution without introducing additional complexity for developers. I believe this would solve a long-standing gap in Xano and remove the need for fragile workarounds that don’t scale well. Curious to hear what others think — and hopefully the Xano team might consider this direction. FA
  • 0

    "Set Cache Value": Support Redis SET NX and boolean return

    Hi Xano Team, I’d like to suggest an improvement to the "Set Cache Value" function to better support high-performance and concurrency-safe architectures. Currently, this function appears to map to the Redis command SET key value EX ttl, which is perfectly fine for general caching use cases. However, in more advanced and professional systems, Redis is not only used for caching but also for distributed locking and preventing race conditions. Redis natively supports this pattern using SET key value NX EX ttl, where the NX flag ensures the key is only set if it does not already exist. This is a widely recommended approach for implementing locks and coordinating concurrent processes. Xano already provides solid support for concurrency control at the database level, for example with PostgreSQL transactions using lock = true. However, there is currently no equivalent mechanism when using Redis through "Set Cache Value". A simple but powerful improvement would be to add an optional parameter (e.g., set_if_not_exists) to this function. When enabled, Xano would execute SET key value NX EX ttl instead of the current command. Additionally, the function could return a boolean value indicating whether the key was actually set. This would enable proper use of Redis for distributed locking, help prevent race conditions in high-concurrency environments, reduce reliance on database-level locks, and align Xano with standard Redis best practices. It would also unlock more advanced backend patterns such as idempotency control and job coordination. Supporting this pattern would significantly expand what developers can safely and efficiently build on Xano. Thanks for considering this improvement. I believe it would add real value for teams building scalable and robust systems on the platform. FA