> ## Documentation Index
> Fetch the complete documentation index at: https://docs.awardee.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Scan-specific knowledge

> Give one chatbot different knowledge depending on what the visitor scanned — the right TV manual for the right room.

A hotel has one chatbot and 100 rooms, each with a different TV. Every room's QR code opens the same chatbot. When a guest asks *"How do I turn the TV on?"*, a chatbot that holds all 100 manuals can only guess which TV they mean.

Scan-specific knowledge fixes this. QR codes, QR groups, products and objects can each link their own articles and folders — the same `article_ids` / `category_ids` a [chatbot](https://docs.awardee.com/chatbots/object.md#knowledge-sources) has. When a visitor scans one and lands on a chatbot, the chatbot searches:

| Visitor arrived by | Knowledge the chatbot searches |
| - | - |
| Opening the chatbot directly | The chatbot's knowledge |
| Scanning a QR code | The chatbot's knowledge **+** the QR code's **+** its group's |
| Scanning a product | The chatbot's knowledge **+** the product's |
| Scanning an object | The chatbot's knowledge **+** the object's |

## The pattern

1. **Link shared knowledge to the chatbot** — breakfast hours, wifi, checkout, house rules.
2. **Link item-specific knowledge to what gets scanned** — each room's TV manual on that room's QR code. If many rooms share a TV model, put the rooms in a [QR group](https://docs.awardee.com/qr-groups/overview.md) and link the manual to the group once.
3. **Keep item-specific articles off the chatbot.** If every manual is also linked to the chatbot, every guest can reach every manual and the ambiguity comes back.

Room 12's guest now searches a set with exactly one TV manual in it, and the chatbot treats "the TV", "this room" and "it" as the thing they scanned.

## Example

```bash cURL theme={null}
# Shared knowledge on the chatbot
curl -X PATCH https://api.awardee.com/v1/chatbots/8f3a9d2e-1b4c-4f5d-9e8a-7c3b2a1d0f9e \
  -H "Authorization: Bearer aw_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "category_ids": ["c3d4e5f6-a7b8-4c9d-0e1f-2a3b4c5d6e7f"] }'

# Room 12's TV manual on room 12's QR code
curl -X PATCH https://api.awardee.com/v1/qr-codes/room-12 \
  -H "Authorization: Bearer aw_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "article_ids": ["5e6f7a8b-9c0d-4e1f-a2b3-c4d5e6f7a8b9"] }'
```

## Rules

* **It only applies to chatbot destinations.** Linked knowledge is used when the scanned item sends visitors to a chatbot — for a QR code in a group, whichever destination wins (the group's, if set). A QR code pointing at a page or URL keeps its links, but they have no effect until it points at a chatbot.
* **Live items only.** Inactive QR codes, products and objects contribute nothing.
* **Same rules as chatbot knowledge.** Only published articles are used, `internal` articles are never used, and every linked id must belong to your organization (`422 unprocessable` otherwise).
* **Replace-only writes.** Send the full desired `article_ids` / `category_ids` set; omit a field to leave it untouched; `[]` detaches everything.
* **Webhooks.** `qr_code.updated`, `qr_group.updated`, `product.updated` and `object.updated` payloads include both arrays, and fire even when a `PATCH` only changes them.

> [!TIP]
>
> Properties are still the right place for small facts about the item (a room number, a serial). Put anything the chatbot should *read and follow* — manuals, procedures, policies — in an article and link it.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.