Quickstart

Import Traces

Bring your existing traces from Langfuse, LangSmith, Braintrust, Raindrop, and Arize Phoenix into Neatlogs.

Already running another observability platform? Import your existing traces into Neatlogs so they live alongside your native data — searchable, filterable, and ready for detections, comments, and the AI assistant like any other trace.

Neatlogs imports from five sources today:

SourceWhat you connect with
LangfusePublic key + secret key + region
LangSmithAPI key + region
BraintrustAPI key + region
RaindropRead API key
Arize PhoenixBase URL + API key

Every imported trace gets a source badge — the platform's icon and name (Langfuse, LangSmith, Braintrust, Raindrop, or Phoenix) shown right in the traces list — so imported and native data are always distinguishable at a glance and filterable by source.


How importing works

There are three pieces, and the UI walks you through them in order:

  1. Connection — your credentials for a source platform, saved once and encrypted. Neatlogs verifies them immediately by listing the projects your key can see.
  2. Project mapping — pick which source project's traces go into which Neatlogs project. You can target an existing project or have Neatlogs create one for you.
  3. Job — the actual import. It runs in the background, fetches traces over the window you choose, and writes them into the target project.

Every import is one of two modes:

ModeWhat it does
One-time backfillImports everything in a fixed date range, then finishes.
Recurring syncBackfills the range, then keeps pulling new traces on a cadence you set (for example every 15m, 1h, 1d, or 1w).

A backfill can also spawn a recurring sync once it completes, so you can migrate history and keep both platforms in sync during a cutover from a single setup.

Self-hosted instances aren't supported. Neatlogs imports run from our cloud, which can't reach private networks — so for most sources you pick a hosted region rather than a custom URL. Phoenix is the exception: because every Phoenix Cloud space has its own URL, you paste that space's base URL directly — but it must be a publicly reachable Phoenix Cloud URL, not a private self-hosted host.


Start an import

You can begin an import in two places:

  • Settings → Integrations — the main entry point for trace imports.
  • Experiments → Prompts → Import — for importing prompt data specifically.

Either way the flow is the same: connect a source, map projects, choose a window, and start the job.


Connect a source

Each source needs a different credential. Pick your platform below for exactly what to grab and where it lives.

FieldWhat to enter
Public keyFrom Langfuse Settings → API Keys — starts with pk-lf-….
Secret keySame screen as the public key — starts with sk-lf-….
Regioncloud.langfuse.com (EU), us.cloud.langfuse.com, jp.cloud.langfuse.com, or hipaa.cloud.langfuse.com.

Both organization-scoped and project-scoped keys work. A project-scoped key surfaces a single project; an org-scoped key surfaces every project it can see.

Connect Langfuse

FieldWhat to enter
API keyFrom LangSmith Settings → API Keys — starts with lsv2_….
Regionapi.smith.langchain.com (US), eu.api.smith.langchain.com, apac.api.smith.langchain.com, or aws.api.smith.langchain.com.

A LangSmith key only works against the one region it was issued for. If you pick the wrong region, the connection fails with an authentication error rather than a redirect — re-check the region your account is on and try again.

In LangSmith, "projects" are sessions; Neatlogs lists each one so you can pick which to import.

FieldWhat to enter
API keyFrom Braintrust Settings → API Keys.
Regionapi.braintrust.dev (US) or api-eu.braintrust.dev (EU).

Like LangSmith, a Braintrust key is region-pinned. Picking the wrong region returns a clear "wrong region" error telling you which region your account is on — switch to it and reconnect.

FieldWhat to enter
API keyThe Read / Query API key from your Raindrop workspace's API Keys page — a long hex string. No region or secret to enter; Raindrop's query API has a single global endpoint.

Raindrop has no native "project" concept, so Neatlogs lists your distinct event names as importable projects. Pick the event name whose traces you want to bring over. Make sure you're using the Read / Query API key, not the SDK write key — they're different keys and the write key won't authenticate here.

FieldWhat to enter
Base URLYour Phoenix Cloud space URL — open Phoenix and copy the host, e.g. https://app.phoenix.arize.com/s/your-space. Each space has its own URL, so there's no region to pick.
API keyFrom Phoenix Settings → API Keys — a system or personal key (a long eyJ… token). Sent as a Bearer token.

Phoenix is the one source you connect with a base URL instead of a region dropdown, because every Phoenix Cloud space lives on its own URL. Paste the full space URL (a trailing slash is fine — Neatlogs trims it). Neatlogs lists the projects in that space so you can pick which to import.

When you save a connection, Neatlogs probes the source right away and shows the projects your key can see. If credentials are wrong or the region is off, you'll see the error before anything is saved — nothing unusable gets stored.


Map projects and choose a window

Once a connection is verified, pick which source project to import and where it lands:

  1. Choose a source project from the verified list.
  2. Choose a target Neatlogs project — either an existing one, or let Neatlogs create a new project named after the source project. Newly created projects come pre-seeded with default detections and your LLM integrations, so detections run on imported traces immediately.
  3. Pick a date range — a preset (last 1d, 1w, 1mo) or a custom window with explicit start/end dates.
  4. Choose a mode — one-time backfill or recurring sync (with a cadence). A backfill can optionally turn into a recurring sync once it finishes.

You can map several source projects at once — select them all, set the window and mode, and Neatlogs creates one import job per project in a single step.


Track and control a running import

Imports run in the background; you don't have to keep the tab open. Each job shows live progress, and where the source reports a total, you'll see an "X of Y traces" bar. (LangSmith, Braintrust, and Raindrop don't always return a total, so those show an indeterminate progress indicator while still importing everything in the window — Langfuse and Phoenix report an exact count.)

Each job surfaces a status:

StatusMeaning
pendingQueued, not yet started.
runningActively fetching and writing traces.
pausedStopped by you, mid-import — progress is kept.
succeededFinished importing everything in the window.
failedStopped on an error (see the last-error message).
cancelledStopped by you for good.

...plus per-run stats:

StatWhat it counts
ImportedNew traces written into the target project.
ReplacedTraces re-imported because they changed at the source.
SkippedTraces unchanged since the last sync, so left as-is.
FailedTraces that errored during this run.
Last errorThe most recent failure message, if a run errored.

You can pause, resume, or cancel any job:

  • Pause / resume — stops fetching without losing progress. A resumed job picks up from where it left off, not from the start.
  • Cancel — stops the job for good.

Imports are safe to re-run and resume. Neatlogs de-duplicates on the way in, so an interrupted backfill, an overlapping window, or a recurring sync that re-reads a boundary trace won't create duplicates in the target project.


After the import

Imported traces appear in the target project's Traces page like any native trace — full span tree, timeline, inputs and outputs, token counts, and costs. The original source platform's structure is mapped onto Neatlogs spans, so a CrewAI run imported from LangSmith looks like a CrewAI run captured natively.

Because every imported trace becomes a first-class Neatlogs trace, everything works on it:

WhereWhat you get
Traces listFull list view, with a source badge (icon + name) on each imported row. Filter to a single source, all imports, or exclude imports entirely.
AI SearchQuery across imported and native traces together.
DetectionsConfigured detections run on imported traces automatically.
CommentsComment on and collaborate over imported traces just like native ones.

The source badge is what keeps imported and native data distinguishable at a glance — handy for verifying a migration, or keeping a clean separation while you evaluate Neatlogs against your current tool.


Troubleshooting

The connection couldn't authenticate against the source.

  1. Double-check the key is correct and hasn't been rotated or revoked at the source.
  2. For LangSmith and Braintrust, confirm you picked the right region — a key only works against the one region it was issued for, and the wrong region returns an auth/region error rather than redirecting.
  3. For Raindrop, make sure you're using the Read / Query API key, not the SDK write key — the write key won't authenticate here.
  4. For Phoenix, confirm the base URL points at the right Cloud space (the same host you see in the browser, e.g. https://app.phoenix.arize.com/s/your-space) and that the API key belongs to that space.
  5. Re-enter the credentials to re-save the connection (a rotated key or changed encryption key invalidates a previously-working connection).

The connection saved but no projects appear to import.

  1. The key is valid but scoped to an org/workspace with no visible projects — check it can see the project you expect at the source.
  2. For Raindrop, this usually means no events have been recorded yet — Neatlogs lists distinct event names as projects, so there's nothing to list until events exist.
  3. For Langfuse, a project-scoped key only surfaces its one project; use an org-scoped key to see them all.
  4. For Phoenix, confirm the base URL points at the space that actually holds your projects — a valid key on the wrong space URL connects but shows that space's (possibly empty) project list.

The import finished but you don't see the traces.

  1. Confirm the date range actually covers when those traces were created at the source.
  2. Verify you mapped the correct source project, not just the account.
  3. Check the job status in Integrations — it may still be running, or have failed with a last-error message.
  4. Try a smaller window first to isolate the issue.

The job stopped with a failed or paused status.

  1. Open the job and read the last-error message — it names the failure.
  2. Confirm the API key is still valid (not rotated/expired) and the region (or base URL, for Phoenix) is right.
  3. Check the source platform's status in case it's down.
  4. Resume a paused job (it continues from where it left off) or re-run a failed one once the cause is fixed.

You think you're seeing duplicate traces.

Neatlogs de-duplicates on the way in by content hash, so an interrupted backfill, an overlapping window, or a recurring sync re-reading a boundary trace won't create duplicates. Apparent duplicates are usually:

  • Different source projects that share trace IDs, or
  • Genuinely distinct traces with similar content but different timestamps.

If you're confident it's a real duplication bug, contact support with the trace IDs that look duplicated.

On this page