rapidapi: fix endpoints, listing links, and the auth step that reads as a dead host

[mtnrabi]

Why

#37 proposes removing these hosts as dead after hitting a 403. The hosts are up, but the 403 is real and the skill genuinely was broken, so both halves are worth fixing. Disclosure up front: I'm the author of the two APIs this skill wraps.

Two separate bugs, and the first one hides the second.

1. The auth requirement is invisible. RapidAPI access is per API, not per account. A key with no subscription to the specific listing gets 403 {"message":"You are not subscribed to this API."} from the RapidAPI edge, which looks exactly like a dead host. The skill said only "RAPIDAPI_KEY is set in .env", so anyone following it saw a 403 and reasonably concluded the API was gone. Verified 2026-08-27: no key gives 401 Invalid API key, an unsubscribed key gives that 403.

2. Every documented call was wrong. Even with a correct subscription, nothing in this skill would have worked:

Documented	Actual
POST /api/v1/searchFlights	POST /api/google_flights/oneway/v1 and /api/google_flights/roundtrip/v1
{origin, destination, date}	{from_airport, to_airport, departure_date}
GET /api/v1/searchHotels?location=	POST /search with {destination, checkin_date, checkout_date}
Source links to rapidapi.com/apiheya/...	rapidapi.com/mtnrabi/... (the apiheya URLs resolve to RapidAPI's generic API Hub placeholder, not a listing)
Free tier "100 requests/month across all RapidAPI APIs"	Per API, not per account. Flights free BASIC is 10/month

What changed

• skills/rapidapi/SKILL.md: correct endpoints, methods, and body fields for all four calls; correct listing links; an Authentication section that spells out key and per-API subscription as two separate steps; a Common Failure Modes table with the exact 401 and 403 bodies; response-field notes (price_insights_low / price_insights_high, buy_link); and the X-Search-Status header so the agent stops reporting a degraded search as "no flights".

I kept the parameter tables to fields I could corroborate today rather than listing everything the APIs accept. A few real parameters are deliberately left out because I could not verify them against the RapidAPI request body from here, and I would rather under-document than repeat the mistake this PR is fixing.

• .env.example: replaces the wrong quota comment with the signup link and both subscribe links.
• CLAUDE.md (+ agents/travel-hacker.md via scripts/sync-agent.sh): the same 100/month claim was in the notes list. Corrected, and it now says a key without a subscription returns 403.

No changes to skill-meta.tsv, README, or llms.txt, so the generated tables do not drift.

The no-key option

The SKILL.md now names a free hosted MCP endpoint of mine, https://google-flights-lulu.flightpowers.com/mcp, which serves the same flight and hotel data with no key and no signup. Verified 2026-08-27: keyless initialize, tools/list, and a real tools/call all return HTTP 200 with live fares.

I documented the caveats rather than filing it under "free", because they matter: it is ad-supported (results carry a sponsored card), there is a daily search budget shared across all callers, and one free-tier flight call covers at most 15 date-by-destination combinations. Given the Ignav thread in #23, I'd rather state that plainly than have you find it.

I deliberately did not add it to .mcp.json, opencode.json, or the zero-key server list in the README. That is a different decision from fixing this skill's docs, and an ad-supported server does not belong in the same bucket as Skiplagged and Kiwi without you deciding that. Happy to open a separate PR if you want it wired in, or to drop the section entirely.

On #37

@danimp94's diagnosis of "this skill is untested" was right; the cause was auth, not a dead host. Their hotel rewrite for Air Scraper is verified and solid. One caveat if it's merged as-is: their own note says Air Scraper's searchFlights returns status: false on v1 and v2, so it would swap a working-but-misdocumented flight API for one whose flight search does not currently return data. I've commented on #37 with the test output.

If the call is that third-party RapidAPI wrappers don't belong in the toolkit, that is reasonable and I won't argue it. This PR is only meant to make the existing skill correct.

Testing

bash scripts/smoke-test.sh --quick
Passed: 14   Failed: 0   Warnings: 1

The one warning is the pre-existing stale-data TTL notice on data/*.json, untouched by this PR.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01L7YoVpT9aAsAPQTv34ZRdj

[mtnrabi]

Closing this — withdrawing. Sorry for the noise.