# Kismet Fixtures

> Discover the real, versioned components that turn Kismet data into bookable guest experiences.


Kismet Fixtures are production React experiences for search, property detail, content, reviews, and booking. A single component contract can ship to WordPress blocks and shortcodes, JavaScript embeds, and npm applications without duplicating the booking behavior underneath it.

The Developer API exposes the real fixture registry: **27 versioned manifests** generated from the shipped component contracts. Each manifest tells a developer or coding agent what the fixture renders, which API operations supply its data, which settings remain editable in Kismet, and which install targets it supports.

## Discover fixtures with the SDK

```ts
import { createKismetClient } from '@kismet-tech/sdk/server';

const kismet = createKismetClient({
  apiKey: process.env.KISMET_DEVELOPER_API_KEY!,
  collection: 'sand-sea-condos',
  baseUrl: 'https://api.ksmt.app/v1',
});

const registry = await kismet.fixture.list();

for (const fixture of registry.data) {
  console.log(fixture.id, fixture.status, fixture.installMethods);
}
```

Use the status filter when an agent should only select fixtures whose data contract is complete:

```ts
const ready = await kismet.fixture.list({ status: 'supported' });
const propertyCard = await kismet.fixture.get('property-card');
```

See [`listFixtures`](https://developers.kismet.travel/api/reference/list-fixtures.md) and [`getFixture`](https://developers.kismet.travel/api/reference/get-fixture.md) for the HTTP contract.

## What the registry contains

The current catalog spans the guest-facing system rather than a set of demo cards:

- search and discovery: results page, search results, map view, filters, property cards, and property sheets;
- property experience: property detail, gallery, header, footer, page shell, and booking CTA;
- content and trust: blog index/detail/cards, reviews, collection pages, and group pages;
- commerce: calendars, checkout, booking confirmation, and rates surfaces.

Every returned manifest includes:

| Field | What a builder can rely on |
| --- | --- |
| `id` and `fixtureVersion` | Stable identity and the component-contract version |
| `status` and `statusReason` | Whether the current Developer API fully supplies the fixture |
| `installMethods` | Supported targets such as npm, block, shortcode, or embed |
| `data[]` | Required operation, capability, coverage, and any declared gap |
| `settings` | Typed dashboard-editable configuration and defaults |
| `themeTokens` | Supported visual tokens without rewriting component internals |
| `enablement` | The collection-level control that turns the fixture on |

## Built to survive customization

Fixtures are not generated markup. Their source contracts, hydration behavior, route ownership, and cross-component communication are protected by TypeScript tests and structural `ast-grep` rules. This is what lets a developer or coding agent compose them while preserving Kismet's data bindings, analytics, booking safeguards, and dashboard controls.

The manifest is the source of truth. Check `data[].coverage` before choosing a fixture, and never infer that an unsupported commercial action exists simply because the visual component exists.