Skip to main content
Installing analytics usually ends with “I think it works”. Dev mode is there so you can see it work: every request your app sends with the development key appears live in the dashboard, with the exact payload and a plain explanation of anything wrong in it.

​
Two keys, one pipeline

Every workspace has two keys meant for the browser:
  • the production API key (orwel_...) for your live site,
  • the development key (orwel_dev_...) for localhost, staging and preview deploys.
Both go through the same ingest pipeline, so what works with one works with the other. The difference is what happens after the data is stored:
Test traffic still counts in your metrics, so keep test runs short. The is_test flag only applies to leads the development key creates: a real customer who converts again from your laptop keeps their real lead.

​
Set it up per environment

Use one variable and give it a different value in each environment. The code never changes, only the key.
.env.local (your machine)
Preview and staging
Production
On Vercel, Netlify or similar hosts, set the development key for the Preview environment and the production API key for Production, so preview deploys never send real lead emails. The variable name changes per framework (PUBLIC_ORWEL_KEY in SvelteKit and Astro, VITE_ORWEL_KEY in Vite); see Install by framework. While you test, add debug: true to see what the SDK does in the browser console:

​
A five minute test run

1

Open Dev mode next to your app

In the dashboard go to Development, Dev mode (/dev-mode). If the section is locked, turn on the development tools with the toggle. Keep it open in a second window.
2

Load a page

A session request should appear within a few seconds. If nothing shows up, see Common problems.
3

Identify yourself

Log in or submit a form that calls orwel.identify({ email }). Check that the identify row has no identify_no_email warning.
4

Fire your custom events

Click through the flows you instrumented. Each track() should be OK; an event_not_found error means that code is not in the catalog yet.
5

Convert once, with a campaign

Open the page with ?utm_source=test&utm_campaign=devmode and submit your main form. The conversion row should show only the test mode note, and the lead appears in Leads with the Dev badge and the test campaign as its source.

​
Reading Dev mode

  • Requests lists everything received with the development key, newest first: type, event code, visitor, endpoint and HTTP status. Filter by status (errors, warnings, OK) or by type, or search by code, visitor, session or any text in the payload.
  • Detail opens one request: the exact payload, each error or warning with the field it refers to and a suggested fix, and the session trace, every other request from the same session in order. The trace is the fastest way to see whether identify really happened before conversion.
  • Event types shows the latest status per kind of request, so one glance tells you whether identify, track and conversion all work.
The HTTP status in each row is the one your app received. The SDK sends events in batches: 200 means every event in the batch was accepted, 207 means some were accepted and some were rejected (open the rejected ones to see why), and 500 means none were accepted.

​
Every check, and how to fix it

Errors mean the event was rejected and not stored. Warnings mean it was stored, but something will make your data worse.

​
Common problems

  • The app is using the production API key, not the development key. Production traffic is not logged in Dev mode. Check the value in the browser: window.orwel exists and the requests to api.orwel.io carry a key that starts with orwel_dev_.
  • orwel.init() never runs: the env var is undefined in this environment (a missing NEXT_PUBLIC_, PUBLIC_ or VITE_ prefix is the usual cause), or the init code only runs on the server.
  • An ad blocker or a strict Content Security Policy blocks api.orwel.io. Try a private window without extensions, and allow https://api.orwel.io in connect-src.
The UTMs have to be in the URL of a page where the SDK runs, before the conversion. Opening the page with ?utm_source=... and converting in the same browser is enough. If the conversion row shows missing_attribution, open its session trace and check the first session request: its URL should contain the UTM parameters.
Each conversion carries a conversionId and the server deduplicates on it, so a retried request creates one lead. Two rows with different ids mean the app called conversion() twice, for example from a submit handler and a success callback. Call it once, after the form is validated.
React Strict Mode runs effects twice in development, so an orwel.init() inside useEffect runs twice. Guard it so it runs once; see Install by framework.

​
Going live

1

Clear the list

Every request in Dev mode should be OK or carry only the test mode note.
2

Swap the key in production

Set the production API key in your production environment and deploy. Leave the development key in preview and local environments.
3

Confirm with one real conversion

Submit your form once on the live site. The lead appears without the Dev badge, the notification email arrives and your integrations receive it. From now on production traffic no longer appears in Dev mode.