> For the complete documentation index, see [llms.txt](https://docs.sygnal.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sygnal.network/build-and-join/running-reference-flows.md).

# Running the reference flows

Import and run the use-case Postman collections against a sandbox.

Each [use case](/use-cases/use-cases.md) ships an importable **Postman Collection v2.1** and a **self-contained environment** in the repository's [`reference-flows/`](https://github.com/Medtronic-LABS/sygnal/tree/main/reference-flows/README.md) folder.

## Quick start

1. **Import** the use case's collection (`Sygnal_UC<n>_…_Postman_Collection.json`) and its environment (`UC<n>_Dev.postman_environment.json`) into Postman.
2. **Select** that environment. Postman allows one active environment at a time, which is why each use case has its own.
3. **Set** `bpp_uri`, `bap_uri`, and any sandbox credentials. `bpp_uri` is the target base URL, and it changes by transaction: for example ComEMR for T1, the campaign platform for UC3, and CARE for UC4's T2.
4. **Check** `network_id`. The shipped value, `example.net/health`, is a placeholder (stub). Replace it with your sandbox network's id. To run against other platforms, join the [Sygnal Sandbox](/build-and-join/sandbox.md).
5. **Run** the requests in order. Each folder walks through one transaction. Matched flows (UC3, UC4's T2) start at `discover`, and directed flows start at `select`. The sequence is: `select` → `on_select` → `init` → `on_init` → `confirm` → `on_confirm` (Referral ID issued) → `status` / `update` steps → closure, plus any deviation branch.

## What the collections contain

| Use case | Folders                                                                                             |
| -------- | --------------------------------------------------------------------------------------------------- |
| UC1      | Referral coordination (DIGIT HCM → ComEMR), with a `NO_SHOW` deviation branch                       |
| UC2      | Emergency referral with an `OBSERVER` on the notification roster, and a `PATIENT_CANCELLED` branch  |
| UC3      | Matched task-out: `discover` → `confirm` → completion                                               |
| UC4      | `T1 · Referral Coordination`, `T2 · PHU Booking on CARE`, `Relay · CARE progress → T1 status chain` |

## Things to know

* **Envelope version.** `context.version` is `2.0.0`, the Beckn core message version. The health schema packs are v2.1; that version appears in their `@context` URLs.
* **Stubs.** Participant ids, keys and document references are stubs. Signing keys are left empty; supply your own sandbox keys, or let your adapter sign.
* **Coded values.** Every coded value's `@context` is the environment variable `codedvalue_ctx`, which points at the network's [code lists](/specification/coded-values.md). To run the flows against another network's lists, change that one variable.
* **Shared values.** Network-wide values are duplicated across the per-use-case environments. Keep them in sync when they change.
* **Scope.** The collections test the **peer-to-peer core**: Beckn transitions, with deviations carried inside the Beckn messages (in-band). Collections for the `sygnal/*` APIs are on the [roadmap](/project/roadmap.md). In the meantime, the [OpenAPI reference](/specification/api-reference.md) has validated example payloads for every Sygnal API.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.sygnal.network/build-and-join/running-reference-flows.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.