Dev mode and the development key

Test your install with a key that never emails anyone, and watch every request arrive live with what to fix.

View as Markdown Open in Claude Open in ChatGPT

Every workspace has two ingest keys: the production API key for production and a development key (orwel_dev_...) for local and staging builds. Data sent with the development key goes through the same pipeline, but it is marked as test data and every request shows up in Dev mode with the problems found in it.

What the development key changes

	Production API key	Development key
Events, sessions, visitors	Stored	Stored
Leads created by a conversion	Normal	Marked `is_test`, shown with a Dev badge
Notification emails for new leads	Sent	Never sent
Integrations (HubSpot, Hyperflow, Zapier, Brevo)	Run	Skipped
Cart abandonment and inbox notifications	Run	Skipped
Each request logged in Dev mode	No	Yes, kept for 7 days

Test traffic still counts in your metrics. A lead that already existed (for example a real customer re-converting from your laptop) keeps its real status: the is_test flag is only set when the development key creates the lead.

Use it

Initialize the SDK with the development key in non production builds, and with the production API key in production. With environment variables that is one value per environment:

.env.local

NEXT_PUBLIC_ORWEL_KEY=orwel_dev_...

Production environment

NEXT_PUBLIC_ORWEL_KEY=orwel_pk_...

Add debug: true to orwel.init() while testing to see the SDK logs in the browser console.

Dev mode

Open Dev mode from the Development section of the dashboard (/dev-mode). Turn on the development tools with the toggle if the section is locked.

Requests: every request received with the development key, live, with its type, event code, visitor, endpoint and HTTP status. Filter by status (errors, warnings, OK) or by event type, or search by code, visitor, session or payload.
Detail: the exact payload, the errors and warnings found in it with a suggested fix, and a session trace with every other request of the same session.
Event types: the latest status for each kind of request, so you can tell at a glance whether identify, track and conversion all work.

What Dev mode checks

Errors mean the request was rejected. Warnings mean it was accepted but something will hurt your data.

Code	Kind	What to do
`event_not_found`	Error	The event code is not in the workspace catalog. Use a catalog code or register yours in a journey or feature.
`invalid_field`	Error	A field is missing or has the wrong type. The detail shows which one.
`missing_session_id` / `session_not_found`	Error	Call `orwel.init()` on every page before `track`, `identify` or `conversion`.
`invalid_batch`	Error	The batch is malformed (`batchId`, `count` and `events` are required, `count` must match).
`payload_too_large`	Error	The request is too large.
`unsupported_type`	Error	Use `track`, `identify`, `session` or `conversion`.
`code_format`	Warning	Event codes must be snake_case (`a-z`, `0-9`, `_`).
`conversion_no_email`	Warning	The conversion has no email or phone, so it cannot be enriched or notified. Add `email` to its properties.
`conversion_no_id`	Warning	No `conversionId`. Update the SDK (`npm i orwel@latest`) so retries are deduplicated.
`missing_attribution`	Warning	No UTMs or ad click ids, so the lead counts as direct. Test with `?utm_source=test` in the URL.
`sdk_outdated`	Warning	The SDK is older than the latest version.
`identify_no_email`	Warning	`identify()` without an email keeps the visitor anonymous.
`test_mode_integrations_skipped`	Info	Stored as a Dev lead. No emails or integrations were sent.

Before you go live

Send one of each
Load a page, trigger an identify(), a track() with each of your custom codes, and one conversion() with an email.
Clear the errors
Every request in Dev mode should be OK or have only the test mode note.
Swap the key
Deploy with the production API key. Production traffic is not logged in Dev mode, and from that moment leads notify and reach your integrations.