Use the tools behind your app

Conversation and Preview can carry your first iteration. When a form fails to save or an email never arrives, inspect the actual data and request behind it. These guides connect the app-building flow to the integrated developer tools in Vortex.

Follow data through the app

Connect to MySQL/MariaDB, PostgreSQL or SQLite, inspect a known row and compare it with the API response. Save requests with environments and the intended authorization, then test a successful, empty and invalid-input case. Use schema and import/export tools with a clear destination.

See what the app sends and reports

Capture development mail locally or through a configured cloud SMTP credential. Inspect its rendered HTML, text and raw content. Signals can receive a fictional test event before you instrument real failures. Local mail heuristics are useful checks, not guaranteed deliverability scores.

Reach saved resources with control

Use saved SSH hosts, tunnels and FTP/FTPS/SFTP connections for the environments you intend. External MCP tools for chats and sharing Vortex tools with a local agent are different directions. Discover resource IDs, keep credentials private and review the scope of writes or remote commands.

Follow the detailed guides

  1. Open your app's database

    Open the data behind the app you are building. If Small Stories saves articles, Database lets you see those stored titles rather than relying only on the page.

  2. Read and change saved data

    Use a table view for a quick inspection, or SQL when you need a more specific question. Both operate on the database connection you selected.

  3. Database structure and relationships

    Column fields, raw defaults, indexes, foreign-key actions, collation, identity reset and diagrams, with engine-specific limits.

  4. Database import and export

    SQL, CSV and JSON exports: structure, content, DROP statements, BLOBs, batching, concurrency, compression and import checks.

  5. API requests and collections

    Understand method, URL, parameters, headers, body, auth, cookies, send, cancel and save with a working sample request.

  6. API environments and authentication

    Configure variables, inherited auth, bearer/basic credentials and every OAuth field, including token refresh and workspace sharing.

  7. Check an API response

    Use the response to answer a concrete question: did the service return the right data, and does it behave correctly when the input changes?

  8. Import, export and sharing

    Bring in existing requests, share clusters through Nexus and review proposed changes.

  9. Connect to a server

    Open a terminal on a server you control when your project needs remote work. A local project shell and an SSH session run on different machines; keep that distinction visible.

  10. Reach a server-side service

    A tunnel lets a local tool reach a service through an SSH server. Use it when the database should not be directly exposed to your computer’s network.

  11. Move files to and from a server

    Use the file-transfer workspace to browse a server and move selected files. Choose the protocol the server actually supports: FTP, FTPS or SFTP.

  12. Edit a remote file

    For a small server-file change, open the file, edit it locally through the supported workflow and let the tracked upload return the saved change.

  13. Capture an email from your app

    Catch an email from your development app before you send real messages. Vortex Mail is a test-email receiver, not a replacement for a personal IMAP inbox.

  14. Capture test mail through cloud SMTP

    Cloud SMTP capture is useful when the test app cannot reach your computer’s local receiver. Create a credential for that app, then find its captured messages in Vortex.

  15. See what a test email looks like

    Check the actual email your app produced: its wording, layout, text alternative and attachments. Select the message and confirm whether it came from local or cloud capture.

  16. Bring an app event into Vortex

    Bring an application event into Vortex so you and your agent can inspect what happened. Start with a deliberate test event before depending on the feed for real errors.

  17. Find the event that needs attention

    Use the feed to find the event that explains a broken app flow. Unread attention and total stored history are different counts.

  18. Add tools to a conversation

    Use built-in project and connection tools in Vortex chats, or add an external MCP server. Discover tools, check status and verify the result.

  19. Let an agent use Vortex tools

    Let a supported local external agent use saved developer resources through Vortex. Credentials are resolved by Vortex rather than pasted into the agent’s resource list.

Explore the Vortex demo or browse all guides.