---
title: Interactive Terminal UIs for API Exploration
description: "We built interactive flight and hotel search right in the terminal — formatted tables, color-coded pricing, and offer selection. Here are the TUI design patterns that work."
canonical: https://nowah.xyz/blog/interactive-terminal-uis-api-exploration
lastModified: "2026-08-07T08:11:45.445Z"
---

# Interactive Terminal UIs for API Exploration

We built interactive flight and hotel search right in the terminal — formatted tables, color-coded pricing, and offer selection. Here are the TUI design patterns that work.

The designer on our team did not believe it. "You can't render a good flight search experience in a terminal." I showed them a formatted table with aligned columns, color-coded prices, airline codes, duration bars, and a selection prompt that piped the chosen offer to a booking command. They stared at it for a moment and said, "Okay, that actually works."

Terminal UIs have a bad reputation because most of them are bad. Walls of unformatted text, confusing prompts, no color, no alignment. But a well-designed TUI can be faster and more focused than a web UI for developer-oriented tasks. The constraint of a text-based interface forces you to prioritize information density and remove visual noise.

We built interactive flight and hotel search directly into our CLI, and developers use it more than we expected.

## Interactive prompts with progressive disclosure

![Illustration for this section](https://pics.nowah.xyz/website-media/developer-experience-017-img-1-prompt-flow.webp)

Running \`nowah [search flights](/blog/launching-[tool-calling](/blog/tool-calling-at-scale-ai-travel-search)\-layer\-ai\-agent\-search\-flights\)\` without any flags launches interactive mode\. The CLI walks the developer through each input field one at a time:

```
Origin (airport code or city): JFK
Destination (airport code or city): CDG
Departure date (YYYY-MM-DD): 2026-06-15
Return date (YYYY-MM-DD, or press Enter for one-way): 2026-06-22
Passengers (adults): 2
Cabin class (economy/premium/business/first) [economy]:
```

Each prompt includes the expected format, a sensible default where applicable, and validation that runs inline. If the developer types an invalid airport code, the prompt shows an error and asks again without losing the previous inputs.

The progressive disclosure matters. We do not dump all five input fields on the screen at once. Each field appears after the previous one is answered. This guides the developer through the search parameters without overwhelming them, especially useful for developers who are new to the API and do not know all the parameters yet.

For developers who know exactly what they want, flag mode accepts everything in one command: \`nowah search flights \-\-origin JFK \-\-dest CDG \-\-date 2026\-06\-15 \-\-return 2026\-06\-22 \-\-pax 2 \-\-cabin economy\`\. Same result, no prompts\. The interactive mode and flag mode produce identical API calls and identical output\.

## Table rendering

Flight search results render as a formatted table with aligned columns:

```
 # Airline Depart Arrive Duration Stops Price
 1 AF 001 08:30 JFK 21:45 CDG 7h 15m 0 $842
 2 DL 400 10:15 JFK 23:30 CDG 7h 15m 0 $867
 3 BA 178 18:00 JFK 06:15 LHR 7h 15m 1 $723
 09:40 CDG (1h 25m)
 4 UA 57 13:20 JFK 03:15 CDG 7h 55m 0 $891
```

The table auto-sizes columns based on the terminal width, with a minimum of 80 columns. On wide terminals, additional columns appear: ranking score, airline rating, layover details. On narrow terminals, the display degrades gracefully by abbreviating column headers and hiding less critical fields.

Prices are color-coded relative to the result set: green for below-average, yellow for average, red for above-average. This gives the developer an instant visual sense of how each option compares without reading every number.

Connection flights (like result #3 above) show the layover on an indented line beneath the main result. The layover duration is shown in parentheses, and the connection airport is visible at a glance.

## Selection and piping

![Supporting diagram](https://pics.nowah.xyz/website-media/developer-experience-017-img-2-table-output.webp)

After displaying results, the CLI prompts for a selection:

```
Select an offer (1-4, or 'q' to quit): 1
```

Selecting an offer prints the full offer details (including the offer ID and all segments) and exits. The selected offer can be piped to other commands:

```
nowah search flights --origin JFK --dest CDG --format json | \
 jq '.offers[0]' | \
 nowah bookings create --stdin
```

This composability is key. Interactive mode is for exploration. JSON output piped between commands is for automation. Both workflows use the same underlying commands and produce the same data. A developer can explore interactively, find the workflow they want, and then script it for repeated use.

The \`\-\-stdin\` flag on \`nowah bookings create\` reads an offer from standard input, allowing it to accept piped output from the search command or from a saved JSON file\. This makes the CLI scriptable end\-to\-end\.

## Responsive layouts

Terminal widths vary wildly. A developer on a 13-inch laptop might have 80 columns. A developer with an ultrawide monitor might have 200+. The table rendering adapts to the available space.

We measure terminal width at render time and use it to decide which columns to show and how wide each column can be. Priority columns (airline, times, price) always show. Secondary columns (ranking score, aircraft type) show only when space allows. Column widths distribute proportionally, with minimum widths to prevent content from becoming unreadable.

Text truncation never breaks mid-word. If a field is too long for its column width, we truncate at a word boundary and add an ellipsis. This is a small detail that makes a significant difference in readability.

## Accessibility

Not everyone uses a terminal with full color support. Some developers use [screen readers](/blog/screen-readers-ai-chat-accessible). Some use high-contrast terminals. Some work in CI environments with no color at all.

The CLI detects terminal capabilities and adapts\. If the terminal does not support color \(detected via the \`TERM\` environment variable and \`NO\_COLOR\` convention\), all output renders in plain text with ASCII\-compatible formatting\. If color is available, we use it for emphasis and information density, but never as the sole carrier of meaning\. The color\-coded pricing also includes text labels that convey the same information for colorblind developers\.

Screen reader compatibility means keeping output linear and avoiding dynamic terminal manipulation where possible. Interactive prompts use standard input patterns that work with assistive technology. We test this periodically and fix issues as they surface.

Building a good TUI is about respecting the medium. The terminal is not a web browser. It has constraints — fixed-width fonts, limited color, no images, no clickable links in most configurations. But within those constraints, a well-designed TUI delivers information faster and with less friction than a web UI for developer tasks. We leaned into those constraints instead of fighting them.

---

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).