> ## 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. # How data gets into Sazabi > Get your logs, metrics, and traces into Sazabi — connect a supported platform account or send to an endpoint — then verify data is flowing. Everything you investigate in Sazabi starts as data you send in. There are two ways to set up a log source: use **Native** to connect a supported platform account and let Sazabi configure forwarding, or use **Manual** to configure a collector, SDK, or agent to send to your log source's intake URL. This page covers how ingestion works and how to choose a path; the rest of the section covers sending frontend, mobile, metrics, and trace data. ## How ingestion works You send data to Sazabi's **intake URL** — the keyed endpoint tied to a log stream, with the shape `https://..intake.sazabi.com`. Copy the whole URL and point your sender at it; because your public key is embedded in the hostname, the URL authenticates the request on its own — there is no separate key or header to send. Sazabi normalizes what arrives — logs, metrics, traces, and webhook events — into a single searchable body of log records that the Sazabi agent queries during an investigation. You get the intake URL from [**Settings > Log streams**](https://app.sazabi.com/settings/log-source-providers): open your log source and copy the **Intake URL** from its setup screen. The public key embedded in it is a low-level credential most customers never handle directly — it lives under [**Settings > Public keys**](https://app.sazabi.com/settings/api) for advanced use. ## Everything is a log Sazabi treats every kind of telemetry as a log. You do not run a separate pipeline per signal type: one intake accepts your data, normalizes it, and stores it as searchable log records. That means one setup path and one place the agent looks when you ask a question. * **Metrics** arrive as OpenTelemetry metrics (or Prometheus metrics relayed through an OpenTelemetry Collector), and each data point becomes a searchable record with its labels and values. See [Send metrics](https://docs.sazabi.com/send-data/metrics.md). * **Traces** arrive as OpenTelemetry traces and are stored as records the agent can search and correlate with your logs by trace context. See [Send traces](https://docs.sazabi.com/send-data/traces.md). * **Webhook events** — deployment notifications, alerts from other tools, and similar signals — arrive at the same intake and become records you can search. See [Webhook events source](https://docs.sazabi.com/catalogs/log-sources/send-to-an-endpoint/webhook-events.md). Because each signal becomes a searchable record, the agent can query logs, metrics, traces, and events in one investigation. Trace identifiers, metric labels, and structured log fields preserve signal-specific context. ## Two ways to set up a log source Pick by where your data lives. * **Native — connect your account** — authorize a supported platform account and let Sazabi configure forwarding. Use this when your platform is in the catalog's Connect-your-account list (for example Vercel, Cloudflare, or Sentry). * **Manual — send to an endpoint** — point a collector, SDK, or agent at your project's intake URL. Use this when you run your own collectors, instrument application code, or your platform is not in the connect-your-account list. Both modes can stream logs continuously. Manual setup gives you control over the sender and forwarding configuration; it does not mean sending logs by hand. ## Choose a path 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/integrations.md#native-connect-your-account) 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/integrations.md#manual-send-to-an-endpoint). **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/send-data/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/send-data/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. ## Browse the log source catalog Every supported source is documented per vendor in the [log source catalog](https://docs.sazabi.com/catalogs/integrations.md#log-sources), split by the same two paths. Start there to find your platform and its exact setup steps. ## In this section > [card] [The Intake page](https://docs.sazabi.com/send-data/intake.md) > > Read ingestion volume and spot anomalies in the dashboard. > [card] [Log storage & retention](https://docs.sazabi.com/send-data/storage.md) > > Where your logs live and how long they are kept. > [card] [Instrument your backend](https://docs.sazabi.com/send-data/backend.md) > > Send logs and traces from backend services with OpenTelemetry. > [card] [Instrument your frontend](https://docs.sazabi.com/send-data/frontend.md) > > Instrument a browser app with the browser SDK or another provider. > [card] [Send metrics](https://docs.sazabi.com/send-data/metrics.md) > > Send and query OpenTelemetry or Prometheus metrics. > [card] [Send traces](https://docs.sazabi.com/send-data/traces.md) > > Send and query OpenTelemetry traces. > [card] [Send Kubernetes audit logs](https://docs.sazabi.com/send-data/kubernetes-audit-logs.md) > > Send API server audit logs from EKS, GKE, or a self-managed cluster. > [card] [Manage log streams](https://docs.sazabi.com/send-data/log-streams.md) > > Enable, disable, reassign, and delete the streams a source produces. > [card] [Troubleshooting ingestion](https://docs.sazabi.com/send-data/troubleshooting.md) > > Diagnose logs that don't show up or arrive malformed. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.