---
title: "The Developer's Travel Workstation: CLI Workflows for API Testing"
description: "Search, book, verify, cancel — all from your terminal. Common CLI workflows for integration testing with shell aliases, test data management, and CI integration."
canonical: https://nowah.xyz/blog/developer-travel-workstation-cli-workflows
lastModified: "2026-08-07T08:11:02.759Z"
---

# The Developer's Travel Workstation: CLI Workflows for API Testing

Search, book, verify, cancel — all from your terminal. Common CLI workflows for integration testing with shell aliases, test data management, and CI integration.

Ten minutes before a feature launch, an engineer ran a quick integration test from the terminal. Search, book, verify, check the webhook. The webhook handler had a bug — it was not storing the booking reference correctly. The engineer caught it, fixed it, and re-tested in under five minutes. All from the terminal.

That story is unremarkable, which is exactly the point. Testing a travel integration should be as fast as running a few commands. Not spinning up a test harness, not clicking through a web UI, not writing throwaway test code. Just terminal commands that exercise the real API.

We designed our CLI workflows around this principle: the full booking lifecycle, from search to cancellation, should be executable in five commands.

## The full booking workflow

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

Here is the complete lifecycle in the terminal:

```
# Step 1: Search for flights
nowah [search flights](/blog/launching-[tool-calling](/blog/tool-calling-at-scale-ai-travel-search)-layer-ai-agent-search-flights) --origin JFK --dest CDG --date 2026-06-15 --pax 2

# Step 2: Book the first result
nowah search flights --origin JFK --dest CDG --date 2026-06-15 --format json | \
 jq '.offers[0]' | \
 nowah bookings create --stdin

# Step 3: Check booking status
nowah bookings get bkg_abc123

# Step 4: Listen for webhooks
nowah webhooks listen --event booking.*

# Step 5: Verify the booking in the trip
nowah bookings list --status confirmed
```

Each step uses a single CLI command. The output of one command feeds the input of the next. The developer can run these manually for exploratory testing or chain them in a script for automated verification.

## Shell aliases for daily testing

Typing \`nowah search flights \-\-origin JFK \-\-dest CDG \-\-date 2026\-06\-15 \-\-pax 2 \-\-cabin economy \-\-format json\` every time you want to test a search is tedious\. Shell aliases compress repetitive commands:

```
# Add to ~/.zshrc or ~/.bashrc
alias nwh='nowah'
alias nwh-search='nowah search flights --origin JFK --dest CDG --date 2026-06-15 --pax 2'
alias nwh-search-json='nwh-search --format json'
alias nwh-book='nwh-search-json | jq ".offers[0]" | nowah bookings create --stdin'
alias nwh-webhooks='nowah webhooks listen --event booking.*'
alias nwh-bookings='nowah bookings list --status confirmed --format table'
alias nwh-logs='nowah logs tail --status 4xx,5xx'
alias nwh-reset='nowah sandbox start --reset'
```

These aliases reduce a multi-flag command to three characters. A developer running quick tests throughout the day saves significant time and keystrokes.

We publish a recommended alias set in our documentation. Teams can customize it for their specific test routes, dates, and configurations. The aliases use the same commands as the full documentation, so there is no hidden complexity.

## Sandbox mode and test data

![Supporting diagram](https://pics.nowah.xyz/website-media/developer-experience-021-img-2-alias-cheatsheet.webp)

The sandbox provides deterministic test data that is isolated from production and resets on demand\. \`nowah sandbox start\` activates sandbox mode for the current CLI session\. All subsequent commands hit the sandbox API instead of production\.

In sandbox mode:

- Search results return deterministic flights and hotels with predictable prices and availability.
- Bookings create without charging real payment methods.
- Webhooks fire with realistic payloads.
- All data resets with \`nowah sandbox start \-\-reset\`, giving a clean slate for each test run\.

The sandbox uses the same API endpoints as production, with the same response shapes and error codes. The only difference is the data source and the [payment processing](/blog/launching-payment-processing-ai-handles-money) (sandbox payments always succeed unless you use a specific test card number that triggers failures).

This means developers can write integration tests against the sandbox and have confidence that the same code will work against production. The behavior is identical; only the data is simulated.

## CI integration

The CLI runs in CI pipelines with the same commands used in [local development](/blog/local-development-microservices). A GitHub Actions workflow for smoke-testing a travel integration looks like:

```
jobs:
 smoke-test:
 runs-on: ubuntu-latest
 env:
 NOWAH_API_KEY: ${{ secrets.NOWAH_SANDBOX_KEY }}
 NOWAH_CLI_VERSION: "2.3.1"
 steps:
 - uses: actions/checkout@v4
 - name: Install Nowah CLI
 run: curl -sSL https://cli.nowah.com/install.sh | sh
 - name: Run smoke tests
 run: |
 nowah sandbox start
 nowah search flights --origin JFK --dest CDG --format json > search.json
 OFFER_ID=$(jq -r '.offers[0].id' search.json)
 echo "Booking offer: $OFFER_ID"
 nowah bookings create --offer-id $OFFER_ID --format json > booking.json
 BOOKING_ID=$(jq -r '.id' booking.json)
 nowah bookings get $BOOKING_ID --format json | jq '.status'
```

The \`NOWAH\_CLI\_VERSION\` environment variable pins the CLI version for reproducible builds\. The sandbox API key is stored as a CI secret\. The test exercises the full search\-to\-book flow and verifies the result\.

This same pattern works in any CI system\. The commands are standard shell\. The JSON output parses with \`jq\`\. No special test framework or SDK required\.

## Building a team playbook

When every engineer on the team uses the same CLI workflows, integration testing becomes consistent and reproducible. We recommend creating a team playbook — a document (or better, a set of shell scripts) that defines the standard test scenarios:

- Basic flight search and booking
- [Multi-city](/blog/multi-city-flight-booking-ai-agents) itinerary booking
- Booking with payment failure (using sandbox test cards)
- Webhook delivery verification
- Cancellation and refund flow

Each scenario is a shell script that runs end-to-end and exits with a success or failure code. New team members can run the playbook on day one to verify their development environment works correctly.

The CLI makes travel API testing accessible. No specialized tools, no complex test harnesses, no learning curve beyond standard terminal skills. Search, book, verify, cancel — all from the terminal, all scriptable, all reproducible.

---

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).