What makes Airbnb Gateway notable?

1.1K downloads. Trust evidence available

How should Airbnb Gateway be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

Airbnb Gateway

A skill for safe, coherent Airbnb operations in OpenClaw-style agent environments. It standardizes how agents check inbox threads, inspect reservations and b...

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.1k

Updated

Oct 11, 2026

Version

0.2.1

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1.1K downloadsadoption · observed Oct 11, 2026
Latest release: 0.2.1release · observed Jul 9, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17b5fr2wfb8eecm8nk9kswmtd87hw31:airbnb-gateway

Install using `clawhub skill install s17b5fr2wfb8eecm8nk9kswmtd87hw31:airbnb-gateway` in an isolated environment before connecting it to live workloads.
No published capability contract is available yet, so validate auth and request/response behavior manually.
Review the upstream CLAWHUB listing at https://clawhub.ai/jason-vaughan/airbnb-gateway before using production credentials.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-jason-vaughan-airbnb-gateway/snapshot"

Documentation

CLAWHUB

147,943 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: airbnb-gateway
description: >
  A skill for safe, coherent Airbnb operations in OpenClaw-style agent
  environments. It standardizes how agents check inbox threads, inspect
  reservations and booking state, review calendar context, draft guest replies,
  send messages safely, verify whether a send actually appeared in the live
  Airbnb thread, and make operator-approved, per-operation, independently-verified
  calendar mutations (block/open dates, nightly price). It teaches a strict operating model: prefer Airbnb-native
  endpoints before generic browser automation; treat send acknowledgments as
  attempted, not automatically confirmed; verify outbound messages in the live
  thread UI before declaring success; and never auto-resend from ambiguous or
  unconfirmed state. Designed to reduce duplicate messages, normalize agent
  behavior, and provide a safer foundation for Airbnb messaging, bookings, and
  calendar workflows — useful standalone today and as a companion to a more
  formal Airbnb adapter/tool layer tomorrow.
version: 0.2.1
risk: write-gated
tags: [airbnb, vacation-rental, messaging, operations, openclaw]
license: MIT
homepage: ""
maintainer: ""
---

# airbnb-gateway

> ⭐ **Find this skill useful?** If `airbnb-gateway` saves you time, please
> **star it** (the ⭐ at the top of this ClawHub page) — stars help other rental
> operators discover it and keep it maintained. Thank you!

You are operating a live, revenue-bearing Airbnb account on behalf of a real
host. Guests are real people. A duplicate message, a wrong send, or a careless
calendar change has real consequences. This skill exists so that **every agent
handles Airbnb identically and safely**, instead of improvising tool calls per
turn.

> **Portability note.** This skill is environment-agnostic. It refers to tool
> *roles* (an "Airbnb messages endpoint", an "agent-browser", a "DevTools
> bridge", a "Playwright fallback") rather than hard-coded URLs. Your concrete
> tool names live in `references/airbnb-tool-priority.md` — edit that one file
> to map roles to the actual tools in your deployment. Everything else here is
> universal.

---

## THE FIVE LAWS (non-negotiable)

1. **Platform-first.** Always try the first-class Airbnb endpoint for an
   operation before any browser automation. Browser weirdness is NOT evidence
   that Airbnb access is down.
2. **Read before write.** Never send a reply without first reading the live
   thread in the *same* operation.
3. **`sent: true` is `attempted`, not `confirmed`.** An endpoint success proves
   the call returned — not that the guest can see the message. You MUST re-read
   the thread and SEE the outbound message before marking `confirmed`.
4. **Never auto-resend an `unconfirmed` send.** Duplicate guest messages are
   worse than a late reply. Escalate to a human instead.
5. **Writes gate; mutations gate harder.** Sending a message is approval-gated.
   Calendar mutations (nightly price, block/open dates) are permitted ONLY

README.md

# airbnb-gateway

A reusable OpenClaw / Codex-style **skill package** for safe, coherent,
end-to-end Airbnb host operations: inbox checks, thread reading, reservation
lookup, booking summaries, calendar inspection, draft replies, **verified**
message sending, and disciplined escalation.

> ⭐ **Find this useful?** If `airbnb-gateway` saves you time, please **star it on ClawHub** — stars help other operators discover it and keep it maintained. Thank you!

It does not add transport. It orchestrates whatever Airbnb tooling your
environment already has — first-class Airbnb endpoints, agent-browser, DevTools,
Playwright — behind one consistent operating model so multiple agents behave
identically and never duplicate a guest message.

## Why this exists

Two reliability lessons are baked into the design:

1. **Browser weirdness ≠ Airbnb down.** Auth is host-owned; prefer platform-aware
   endpoints before generic browser automation.
2. **`sent: true` ≠ delivered.** A send is only `confirmed` after re-reading the
   live thread and *seeing* the message. Endpoint success is just `attempted`,
   and an `unconfirmed` send is **never** auto-resent.

## Install / use

1. Drop `skills/airbnb-gateway/` into your skills library.
2. Edit **`references/airbnb-tool-priority.md`** — map the abstract tool roles to
   the real tool names in your deployment. This is the only required
   customization.
3. (Optional) Set your approval policy and wire a persistent send ledger.
4. Point your agents at the skill. They should speak only in the command verbs
   (`check_inbox`, `read_thread`, `send_reply`, …) and never call low-level
   Airbnb tools directly.

## What's portable vs. deployment-specific

| Portable (don't fork) | Deployment-specific (customize) |
|---|---|
| The Five Laws | role → tool name map |
| Send state machine | approval policy |
| Safety tiers (READ/WRITE/MUTATE) | persistent ledger wiring |
| Command vocabulary | example payload shapes |

## Layout

```
airbnb-gateway/
├── SKILL.md                              # the operating contract (start here)
├── README.md                             # this file
├── CHANGELOG.md
├── LICENSE
├── references/
│   ├── airbnb-tool-priority.md           # ← customize per deployment
│   ├── airbnb-message-state-machine.md   # universal
│   ├── airbnb-safety-rules.md            # universal
│   └── future-adapter-interface.md       # how to pair with a code adapter later
├── examples/
│   ├── check-inbox.md
│   ├── read-thread.md
│   ├── send-reply-with-verification.md   # the critical path
│   ├── reservation-lookup.md
│   └── calendar-inspection.md
└── state/
    └── send-log.schema.json              # append-only dedupe ledger schema
```

## Status

v0.2.x — read operations, verified single-send, and **approval-gated calendar
mutations** (block/open dates, nightly price) under an explicit per-operation
approval gate with mandatory fresh-load verification (tier MUTATE-CAL). Listing
edits, accept/decline, and refunds rema

_meta.json

{
  "ownerId": "kn77gtjzdkfywnsbs5f349wjxd87hb0x",
  "slug": "airbnb-gateway",
  "version": "0.2.1",
  "publishedAt": 1783632040243
}

references/airbnb-message-state-machine.md

# Reference — Airbnb message send state machine

This is the authoritative definition of the send discipline. `SKILL.md` carries
the operational summary; this file carries the full machine, timings, and edge
cases. **This logic is universal — do not fork it per deployment.**

## States

| State | Meaning | Terminal? |
|---|---|---|
| `drafted` | Reply text composed, thread + dedupe-key recorded. Nothing sent yet. | no |
| `attempted` | Send endpoint called exactly once and returned. **Delivery NOT proven.** | no |
| `confirmed` | Outbound message verified visibly present in the live thread. | yes ✅ |
| `unconfirmed` | Send returned but the message could not be seen after the verify window. | yes ⚠️ |
| `failed` | The send call itself errored (4xx/5xx/timeout). | yes ❌ |

## Transitions

```
            approval (if required)              send endpoint
  drafted ───────────────────────► (ready) ───── exactly once ─────► attempted
                                                                         │
                                              re-read same thread        │
                                          ┌──────────────────────────────┤
                                          │                              │
                            visible ◄─────┘                              └─────► call errored
                               │                                                     │
                               ▼                                                     ▼
                          confirmed ✅                                            failed ❌
                                                                                     │
                            absent after verify window                               │
                               │                                                     │
                               ▼                                                     ▼
                         unconfirmed ⚠️  ◄──────── (treat like) ──────────── re-read thread
                               │                                                     │
                               └──────────► ESCALATE. No automatic resend. ◄─────────┘
```

## The dedupe-key

`dedupe_key = hash(thread_id + "\n" + normalize(draft_text))`

`normalize` = trim, collapse internal whitespace, lowercase. The key makes "the
same reply to the same thread" idempotent regardless of retries.

## The ledger (duplicate-prevention backbone)

An append-only record, ideally persisted (survives restarts). One row per
`attempted`:

```json
{
  "dedupe_key": "…",
  "thread_id": "…",
  "attempted_at": "ISO-8601",
  "final_state": "confirmed | unconfirmed | failed",
  "verified_at": "ISO-8601 | null",
  "operator": "agent-id | human-id"
}
```

Rules:
- Write the row at `attempted`, **before** verifying. A crash between send and
  verify must never look like "never sent."
- Before any new send, check the ledger for the dedupe-key:
  - `confirmed

references/airbnb-safety-rules.md

# Reference — Airbnb safety rules

The portable safety contract. Universal — do not weaken per deployment. The only
deployment-specific knob is the **approval policy** (who approves, and whether
approval is required for sends).

## Operation tiers

| Tier | Definition | Examples | Default gate |
|---|---|---|---|
| **READ** | Cannot change anything a guest or the host can see. | check inbox, read thread, lookup reservation, booking summary, inspect calendar, verify a sent message | None — proceed. |
| **WRITE** | Produces something a guest sees, but bounded & verifiable. | send a guest reply | Approval (if configured) **+ mandatory verify**. |
| **MUTATE-CAL** | Affects availability or pricing on the live listing; hard to reverse. | change nightly price, block/open calendar dates | **Explicit per-operation operator approval** (APPROVED keyword, one op per approval) **+ mandatory fresh-load verify + reported inverse.** See `calendar-mutation-procedure.md`. |
| **MUTATE-RESTRICTED** | Affects listing content, booking decisions, or money movement; effectively irreversible. | edit listing, accept/decline a booking, issue a refund, payouts | **Not implemented — refuse + escalate.** (Each would get its own gated workflow before ever being enabled.) |

Classify every operation into exactly one tier *before* acting. If an operation
spans tiers, split it; never let a READ workflow quietly perform a WRITE.

## Approval gate (WRITE)

- Per-message, never standing. One approval authorizes exactly one send of one
  draft to one thread.
- Present to the approver: the target thread id, the last inbound guest message,
  and the full draft text. Wait for explicit "go".
- Deployment policy decides whether approval is *required*. Safe default:
  required for all guest-facing sends. If disabled, verification is still
  mandatory.

## Irreversibility boundary

Treat everything a guest can see, and anything touching money or availability,
as irreversible in practice. You cannot reliably "unsend". This is why:
- WRITE ops always verify after the fact.
- MUTATE-CAL ops (calendar/price) run only under explicit per-operation approval
  and are fresh-load verified after — never attempted optimistically.
- MUTATE-RESTRICTED ops (listing edits, accept/decline, refunds, payouts) are
  refused outright rather than attempted.

## Ambiguous state — the default is caution

| Ambiguity | Action |
|---|---|
| Can't tell if a send landed | `unconfirmed`. Do NOT resend. Escalate. |
| Two read paths disagree on a material fact (dates, guest count, price) | Report BOTH, flag the discrepancy, escalate. Do not silently pick one. |
| Browser identity health unclear | Check the browser health role; if unhealthy, escalate rather than assuming. |
| Ledger state unknown after restart | Verify by reading the live thread before any send. |

## Escalate to a human when

- A send reaches `unconfirmed` or `failed`.
- You are asked to perform any MUTATE-RESTRICTED operation, or a MUTATE-CAL
  opera

Github ReposUpdated 2d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.