Tixxly for AI agents

    The Agentic Commerce Protocol surface Tixxly exposes so AI agents can read and transact against tour and activity suppliers without writing custom integrations per supplier.

    Discovery

    An agent that lands on any Tixxly storefront finds the surface by reading two well-known files:

    • agents.txt— policy file in prose. What we allow and what we don’t.
    • actions.json — machine-readable manifest. Every action with method, path, request schema, response schema, idempotency posture, and feature-flag state.

    Both files are served at two scopes. The platform scope (tixxly.ai/agents.txt, tixxly.ai/actions.json) is read-only and delegates transactional verbs back to per-supplier URLs. The per-supplier scope (stores.tixxly.ai/{locale}/v/{vendor_slug}/agents.txt and the matching actions.json) carries the full surface including transactional verbs. Suppliers with custom domains serve the same files at their own origin.

    Posture

    • All suppliers by default. Every active supplier is reachable through the ACP surface. There is no per-supplier opt-out.
    • Empty-render. Missing fields come back as null or are omitted. We never invent placeholder data.
    • Intent-only today. The transactional verb records an intent. Payment authorisation and supplier-side locking ship in a later iteration alongside AP2.
    • Rate limit. 100 req/min/IP at the gateway. Email partnerships@tixxly.ai for higher throughput.

    Verbs

    1. viewItem (read-only)

    GET /v1/experiences/{experience_id} — the canonical single-product read. experience_id accepts either the internal numeric id or the Bokun external id.

    2. checkAvailability (read-only)

    POST /v1/agents/availability — vendor-scoped slot lookup. Body:

    {
  "vendor_slug": "immmersiv",
  "product_id": "12345",
  "date": "2026-06-15",
  "party_size": 2,
  "currency": "USD",
  "language": "EN"
}

    Returns up to ten slots filtered by party_size, plus a policy_endpoints placeholder (cancellation, refund, accessibility) populated in a later iteration.

    3. bookIntent (transactional)

    POST /v1/agents/book-intent— records an agent’s intent to book on behalf of a buyer. Nothing is charged, nothing is locked at the supplier. A buyer-facing confirmation_url is returned so a human can close the loop.

    Required headers:

    • X-Agent-Id — free-form today. AP2 will verify against a registry of signed identities.
    • Idempotency-Key — required. Replays return the original intent_id.

    Body:

    {
  "vendor_slug": "immmersiv",
  "product_id": "12345",
  "date": "2026-06-15",
  "slot_start": "2026-06-15T09:00:00",
  "party_size": 2,
  "currency": "EUR",
  "buyer": {
    "name": "Alex Buyer",
    "email": "alex@example.com",
    "phone": "+30 21 0000 0000"
  }
}

    Response (201):

    {
  "success": true,
  "data": {
    "intent_id": "9c8d6f24-...",
    "status": "recorded",
    "confirmation_url": "https://stores.tixxly.ai/confirm/9c8d6f24-...",
    "expires_at": "2026-05-30T12:00:00Z"
  }
}

    bookIntent is feature-flagged on ENABLE_AGENT_BOOKING. When the flag is off, the endpoint returns 503. Default off in production, on in staging.

    Identifiers

    • Vendor slug — public, stable. Used in storefront URLs, llms.txt, sitemaps, and ACP request bodies.
    • Product id — either internal numeric id (from llms.txt and storefront PDP URLs) or Bokun external id. Both work everywhere.
    • Intent id — UUID returned by bookIntent. Used by the buyer-facing confirmation page and, later, AP2.

    What’s not in this iteration

    • Payment authorisation, real-time supplier-side locking, and refund flows — these ship with AP2.
    • Real policy_endpoints URLs — populated in a follow-up iteration alongside UCP coverage.
    • Signed agent identity — free-form X-Agent-Id today, registry-verified with AP2.

    Contact

    Partnerships and agent onboarding: partnerships@tixxly.ai. Technical questions: open an issue on our public docs repo or write to agents@tixxly.ai.