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

# Hands-on Use Cases

> Complete, outcome-oriented DataRelay Control walkthroughs with inputs, UI actions, success checks, and recovery.

# Hands-on Use Cases

Choose what you want to accomplish. Each guide includes a starting state, numbered actions in the actual Control UI, expected evidence, and recovery steps. The guides are for the development implementation in `datarelay-labs/datarelay-control` **main-v2 @ f7ae7b35 (18 October 2026)**, not a blanket assertion that every feature has passed release or browser acceptance.

> [!WARNING]
>
> Use synthetic events and a non-production environment. Do not paste live tokens, production personally identifiable information, or a private customer's log data into the examples. Actual Control browser E2E is still in progress ([product verification issue #413](https://github.com/datarelay-labs/datarelay-control/issues/413)); a successful preview is not proof of delivery.

**Prefer visuals?** Follow the [numbered Stream Wizard screenshots](https://control.datarelay.run/use-cases/screen-walkthrough.md), from Connector selection to deployment and Logs.

## Connector-first workflow

**① Review the vendor API guide → ② Prepare access/auth/sample data → ③ Ask ChatGPT with public documentation and redacted samples if uncertain → ④ Create and test Connector → ⑤ Create Destination → ⑥ Create Stream and confirm records/checkpoint → ⑦ Mapping, masking and supported tokenization → ⑧ Deploy → ⑨ Verify Logs and real receiver → ⑩ Troubleshoot delivery/schema drift.**

Each Connector guide now starts with its specific inputs, an actionable ChatGPT prompt, the full UI workflow and failure diagnostics. Screenshots must be authentic and version-verified; do not treat placeholders as product evidence.

## Start here

1. [Prepare a safe lab](https://control.datarelay.run/use-cases/lab-setup.md) — a runnable Python HTTP receiver, test payload, and connectivity checks.
2. [Webhook → first delivered event](https://control.datarelay.run/use-cases/webhook-first-flow.md) — create Connector, Destination, Stream, Route, and verify the receiver.
3. [HTTP API collection](https://control.datarelay.run/use-cases/http-api.md) — configure a real API Connector, sample records, and checkpoint behavior.

## More source and destination integrations

| Integration | Follow this |
| - | - |
| Security event to a Syslog/UDP collector | [Syslog Destination](https://control.datarelay.run/use-cases/syslog-delivery.md) |
| Read audit rows from a database | [PostgreSQL collection](https://control.datarelay.run/use-cases/postgresql-collection.md) |
| Import JSONL logs from object storage | [S3 / MinIO collection](https://control.datarelay.run/use-cases/s3-object-collection.md) |
| Read event files from a remote SSH server | [SFTP file collection](https://control.datarelay.run/use-cases/sftp-file-collection.md) |
| Run the daily health/incident workflow | [Daily operations](https://control.datarelay.run/use-cases/daily-operations.md) |

## Delivery and processing scenarios

| Your goal | Follow this |
| - | - |
| Send the same event to two systems, each with its own fields | [Two destinations, two Routes](https://control.datarelay.run/use-cases/multi-destination.md) |
| Mask personal data only for an external receiver | [Per-Route sensitive data protection](https://control.datarelay.run/use-cases/protect-pii.md) |
| Handle added, missing, or modified fields | [Schema change and review](https://control.datarelay.run/use-cases/schema-change.md) |
| Hold suspicious events and make a review decision | [Quarantine, release, and replay](https://control.datarelay.run/use-cases/quarantine-replay.md) |
| Investigate a failed delivery and restore the sink | [Delivery incident response](https://control.datarelay.run/use-cases/delivery-incident.md) |
| Save filters and export incident evidence | [Logs, saved views, and exports](https://control.datarelay.run/use-cases/logs-audit.md) |
| Adopt a built-in or installed integration | [Marketplace to Stream](https://control.datarelay.run/use-cases/marketplace-install.md) |

## Mental model

```text theme={null}
Source / Connector → Stream → Route A → Destination A
                            └→ Route B → Destination B
```

**Stream** is the execution unit. A **Route** is the destination-specific processing unit; do not duplicate a Stream just to get different outbound transformations. Work in this order: **Connect → Sample & Record Selection → Destinations → Route Processing → Deploy**.

## Evidence checklist for every scenario

* Connection or Source test shows the expected sample or an explicitly recorded limitation.
* Deploy shows readiness; warnings are reviewed, not silently ignored.
* Stream is active and a new run is visible.
* Each expected Route has a matching delivery log and a receiver-side record (when delivery applies).
* A failed, quarantined, or blocked event is **not** counted as successful delivery.

See also [First Stream](https://control.datarelay.run/getting-started/first-stream.md), [Route Processing](https://control.datarelay.run/processing/route-processing.md), [Known Limitations](https://control.datarelay.run/reference/limitations.md), and [Korean walkthroughs](https://control.datarelay.run/ko/use-cases/index.md).


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