Agent Surface

    Agentic Commerce Protocol (ACP)

    A public API surface that lets AI agents discover tour and activity suppliers, query availability and record booking intentions — without a custom integration per vendor.

    Audience

    Who this is for

    This reference is written for AI agents, developers building agent-based travel commerce systems, and technical integrators. It describes how the surface is discovered, how it behaves, and the operations it supports.

    Discovery

    Agents locate the surface through two files. agents.txt states the policy in prose: who may use the surface, what is permitted, and how it should be used. actions.json is the machine-readable manifest describing the available actions and their shapes.

    Both files exist at two scopes: platform scope, covering the surface as a whole, and per-supplier scope, covering a single vendor identified by its slug. An agent typically reads the platform files first, then the supplier files for the vendor it is working with.

    Posture

    All suppliers by default

    Every supplier on the platform is exposed to the agent surface by default. Agents do not need a per-vendor integration, contract or onboarding step to discover and query a supplier.

    Empty-render for missing fields

    Fields that a supplier has not provided are rendered empty rather than omitted or faked. Agents should treat an empty value as unknown, not as a negative assertion.

    Intent-only transactions

    The surface records booking intent. It does not authorize payment. A recorded intent returns a confirmation URL where the traveller completes the booking.

    Rate limiting

    Requests are limited to 100 requests per minute per IP address. Agents exceeding the limit receive a throttled response and should back off.

    Verbs

    The surface exposes three operations.

    viewItem (GET)

    Retrieves the details of a single product: title, description, duration, pricing and the supplier it belongs to. Fields the supplier has not provided are returned empty.

    checkAvailability (POST)

    Looks up available time slots for a product on a given date and party size. Availability is informational and does not reserve or lock inventory.

    Request
    {
  "vendor_slug": "example-tours",
  "product_id": "12345",
  "date": "2026-10-04",
  "participants": { "adults": 2, "children": 1 }
}
    Response
    {
  "product_id": "12345",
  "date": "2026-10-04",
  "currency": "USD",
  "slots": [
    { "start_time": "09:00", "available": 8, "price": 74.00 },
    { "start_time": "13:30", "available": 3, "price": 74.00 }
  ]
}

    bookIntent (POST)

    Records a booking intention. Requests must include an X-Agent-Id header identifying the calling agent and an Idempotency-Key header so a retried request does not create a duplicate intent. The response returns an intent_id and a confirmation_url where the traveller completes the booking. No payment is authorized.

    Request
    POST /acp/bookIntent
X-Agent-Id: example-agent
Idempotency-Key: 7f1c2b9a-0d44-4f5f-9f0a-2a7d1c83e511

{
  "vendor_slug": "example-tours",
  "product_id": "12345",
  "date": "2026-10-04",
  "start_time": "09:00",
  "participants": { "adults": 2, "children": 1 },
  "customer": { "name": "Alex Doe", "email": "alex@example.com" }
}
    Response
    {
  "intent_id": "int_9c2f41ab",
  "status": "recorded",
  "confirmation_url": "https://book.tixxly.ai/intent/int_9c2f41ab",
  "expires_at": "2026-10-03T23:59:59Z"
}

    Identifiers

    Vendor slug

    A stable, human-readable string identifying a supplier. It scopes the per-supplier agents.txt and actions.json files and appears in every supplier-scoped request.

    Product ID

    Identifies a single product for a supplier. It is either a numeric Tixxly product ID or a Bokun external product ID, depending on how the supplier's inventory is connected.

    Intent ID

    Returned by bookIntent. It identifies the recorded intention and is used to correlate the agent's request with the traveller-facing confirmation flow.

    What’s not included

    The following are deliberately out of scope in the current surface and are deferred to a future AP2 iteration.

    • Payment authorization — the surface records intent only and never charges a traveller.
    • Real inventory locking — availability responses are informational and do not hold a slot.
    • Refund and cancellation flows — these remain with the supplier's own booking system.
    • Policy endpoints — machine-readable cancellation, age or accessibility policy is not exposed yet.
    • Signed agent identity — X-Agent-Id is self-declared and not cryptographically verified.

    For the OpenAPI 3.1 specification and platform integration overview, see the Developers page.

    Looking for commercial API access as a supplier? See Vendor API access on the Infrastructure tier.