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

# Choosing an ingestion path

> A decision guide for getting data into Sazabi — connect a supported account, run your own collectors, or instrument application code.

Sazabi supports two setup modes: **Native — connect your account**, and **Manual — send to an endpoint**. Manual covers several sending methods. This page helps you pick. For most projects, start by checking whether your platform is in the connect-your-account list; it is the least setup.

## Native versus manual

The difference is who configures delivery, not how often logs arrive. Both modes can stream logs continuously.

| Mode | What Sazabi does | What you configure |
| - | - | - |
| **Native** | Connects to a supported platform and configures log forwarding. | Authorize your account and select the data to collect. |
| **Manual** | Provides a keyed intake URL for your log source. | Point your platform, collector, SDK, or application at the URL and configure what it sends. |

Choose native when Sazabi supports your platform and you want it to configure forwarding. Choose manual when you already operate a sender, instrument application code, or want control over what you forward. Some platforms support both modes.

## Is your platform a supported cloud platform?

**Recommended when:** your logs live on a platform Sazabi can connect to directly (for example Vercel, Cloudflare, Sentry, Google Cloud, or AWS CloudWatch).

**Use native setup.** You authorize Sazabi once and it configures log forwarding — no collector to run and no key to embed in your infrastructure. Browse the [Connect your account](https://docs.sazabi.com/catalogs/log-sources/connect-your-account.md) list to see if your platform is there.

**Use an alternative when:** your platform is not in the list, or you want explicit control over exactly which records leave your environment.

**Trade-offs:** least setup and no infrastructure to maintain, but you get the data the platform exposes to Sazabi rather than a stream you shape yourself.

**Do not use when:** your platform is not in the connect-your-account list.

## Do you run your own collectors?

**Recommended when:** you already run an OpenTelemetry Collector, Grafana Alloy, Fluent Bit, Vector, or a Datadog Agent.

**Use manual setup with your collector.** Add your project's intake URL as a destination. This keeps your existing pipeline and adds Sazabi as one more sink. See the collector entries under [Send to an endpoint](https://docs.sazabi.com/catalogs/log-sources/send-to-an-endpoint.md).

**Use an alternative when:** you do not run a collector and do not want to.

**Trade-offs:** full control over what you forward and how it is shaped, at the cost of running and maintaining the collector.

**Do not use when:** connecting your account covers your platform with less work.

## Are you instrumenting backend code?

**Recommended when:** you want telemetry from inside your backend — logs and traces emitted by the application itself.

**Use manual setup with the OpenTelemetry SDK.** Point it at your log source's intake URL and it sends logs and traces as your code runs. See [OpenTelemetry](https://docs.sazabi.com/catalogs/log-sources/send-to-an-endpoint/opentelemetry.md).

**Use an alternative when:** the data you need is already available by connecting your platform account, or a collector you run already ships it.

**Trade-offs:** the richest, most application-specific data, at the cost of code changes.

**Do not use when:** a platform connection already gives you the signals you need.

## Are you instrumenting a frontend app?

**Recommended when:** you want browser-side telemetry — errors, console output, network activity, and interaction events from your users' browsers.

**Use manual setup with the Sazabi browser SDK.** It captures a semantic event stream and injects trace context so browser events correlate with your backend logs. See [Instrument your frontend](https://docs.sazabi.com/guides/instrument/frontend.md).

**Use an alternative when:** you already run Sentry or PostHog in the browser — repoint that SDK at your intake URL instead of adding a second one. The [frontend guide](https://docs.sazabi.com/guides/instrument/frontend.md) compares the options.

**Trade-offs:** first-party browser capture with backend correlation, at the cost of adding one SDK to your app.

**Do not use when:** you do not control the frontend build.

## Mixing paths in one project

You can use more than one path in the same project. A common setup connects a cloud platform account for infrastructure logs and instruments application code with OpenTelemetry for request-level detail. Everything lands in the same searchable set of log records regardless of how it arrives.

## Further reading

> [card] [Browse the log source catalog](https://docs.sazabi.com/catalogs/log-sources.md)
>
> Find your platform and its exact steps.


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