Recent Announcements

Tue, Jun 30

State of Xano: Q2 2026

Hello Xano Developers! 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.
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.

Latest Posts

  • Angelo Bendrot

    Add support for the HTTP QUERY method (RFC 10008)

    Request: Add QUERY as a supported HTTP method in (1) External API Request function stacks, for calling third-party QUERY-enabled APIs, and (2) custom API endpoint definitions, so Xano-hosted endpoints can accept QUERY requests natively. 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: 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. 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).
    0
    0
    Thu, Jul 2
  • Prakash Chandran

    State of Xano: Q2 2026

    Hello Xano Developers! 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.
    5
    1
    Tue, Jun 30
  • Bas van Ginkel

    Middleware: using auth.id - suggestion welcome.

    Hey all 👋 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! 🙏
    0
    4
    Tue, Jun 30

Recent Activity

  • Bas van Ginkel
    Bas van Ginkel
    ·Posted in Discuss

    Middleware: using auth.id - suggestion welcome.

    Hey all 👋 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! 🙏
    0
    4
    Tue, Jun 30
    Security
  • Marinette Thomas
    ·Posted in Discuss

    Optimizing third-party API orchestration, data transformation, and response caching in Xano

    Hi all, I’m currently in the process of optimizing the backend data flow for my platform, Astroma. We are migrating our core logic over to Xano to take advantage of its powerful API orchestration and background processing capabilities, but I've run into a structural question regarding API efficiency. 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!
    0
    2
    Mon, Jun 29
    Other
  • Laura Richards
    ·Posted in Discuss

    Timeout errors on background tasks with Agents

    Hi all, new here but wanted to check something as I can’t find it in the documentation anywhere. 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!
    0
    1
    Thu, Jun 25
    Working with APIs

Latest Feature Requests

  • 0
    Angelo Bendrot

    Add support for the HTTP QUERY method (RFC 10008)

    Request: Add QUERY as a supported HTTP method in (1) External API Request function stacks, for calling third-party QUERY-enabled APIs, and (2) custom API endpoint definitions, so Xano-hosted endpoints can accept QUERY requests natively. 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: 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. 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).
  • 3
    Angelo Bendrot

    Add folders or grouping for database triggers

    Would it be possible to add folders or grouping for database triggers? 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!
  • 1

    auth.extras mock for testing

    Hi 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
  • 1

    Real-Time / WebSocket monitoring section in Monitor dashboard

    I would like to suggest a dedicated Real-Time / WebSocket monitoring section within the Monitor dashboard. Currently, the Monitor tab provides a consolidated view of several important metrics, such as overall performance and errors, which makes it a very useful place to understand the health of an application. However, there is currently no equivalent visibility into the Real-Time layer. For applications that rely on WebSockets and Real-Time features, it would be extremely valuable to have a dedicated monitoring section similar to Performance Insights, focused specifically on Real-Time activity. This section could display metrics such as the number of connected users/sessions, active channels, messages received, events published, connection/disconnection rates, and historical trends over time. Having this information available in a centralized monitoring dashboard would make it much easier to understand system usage, troubleshoot issues, identify unusual activity, and evaluate the adoption of Real-Time features. At the moment, there is no consolidated way to observe what is happening within the Real-Time infrastructure, and adding such a view would significantly improve observability for applications that depend on WebSockets. FA
  • 1

    Redis monitoring section in Monitor dashboard

    For applications that make extensive use of caching, rate limiting, queues, sessions, or other Redis-based features, having better observability into Redis would be extremely beneficial. A dedicated Redis monitoring section could provide insights such as the total number of keys, key creation and deletion rates, storage utilization, memory consumption trends, cache hit and miss rates, expiration activity, and historical usage patterns over time. It could also help identify unexpected growth in key counts, excessive key churn, inefficient cache usage, or storage-related issues before they impact application performance. Having these metrics available directly within the Monitor dashboard would make it much easier to understand how Redis is being used across an application and to troubleshoot performance or scaling issues. Currently, there is limited visibility into Redis activity, and a dedicated monitoring view would significantly improve operational awareness and platform observability. FA