new TappdSDK(config), you pass a configuration object that controls how the SDK behaves — from session timeouts and page-view tracking to in-app message delivery and debug logging. Only appId is required; every other option has a sensible default you can override as needed.
Full configuration example
The snippet below shows every available option with its default value. Copy it as a starting point and remove any options you don’t need to change.Configuration reference
Your unique App ID from the Tappd dashboard. This identifies your application and is required for every SDK operation. Find it under Settings → Apps in your Tappd Dashboard.
The API endpoint the SDK sends data to. You only need to change this if you’re using a self-hosted Tappd instance or a custom domain.
Automatically records page views on the initial load and on every client-side navigation. This includes History API changes (push/pop state), which means single-page applications built with React Router, Vue Router, and similar libraries are tracked without any extra setup.Set this to
false only if you want to call tappd.trackPageView() manually on every route change.The number of minutes of user inactivity that triggers a new session. After the timeout elapses, the next user action starts a fresh session. Adjust this to match how your users typically interact with your application — a content site might use a longer timeout, while a transactional app might use a shorter one.
When enabled, the SDK automatically listens for link clicks (
<a> tags) and form submissions and records them as events — no manual track() calls needed. Link clicks fire a link_click event; form submissions fire a form_submit event, both with relevant metadata attached.Leave this disabled if you prefer to track interactions explicitly, which gives you more control over the event names and properties you capture.Enables the in-app messaging system, which lets you fetch and display banners, popups, and modals created in the Tappd dashboard. Set this to
false to disable all in-app message functionality globally, regardless of other message-related settings.When
true, the SDK automatically fetches pending in-app messages from the API and displays any that match the current user’s targeting rules. Requires enableInAppMessages to also be true.Set this to false if you want to control when messages appear — for example, only showing them on certain pages or after specific events.How often, in seconds, the SDK checks for new in-app messages. Only applies when
autoDisplayMessages is true. Lower values mean users see new messages sooner; higher values reduce API requests.The
id of a DOM element to render in-app messages into. If you don’t set this, messages are appended directly to <body>. Use a custom container to control exactly where messages appear in your layout — for example, inside a fixed header or notification area.Enables verbose logging to the browser console. When
true, the SDK logs every operation — initialization, session events, tracked events, identified users, and message fetches — prefixed with [Tappd SDK].Always set this to false in production to keep your console output clean.Environment-based configuration
Development vs. production
Keep your development and production configurations separate using environment variables and aNODE_ENV check. This pattern enables debug logging locally without any risk of enabling it in production.
Multiple environments
If you maintain separate Tappd apps for development, staging, and production, use an environment-keyed config object to switch between them automatically.Common environment variable names
| Build tool | Variable format |
|---|---|
| Vite | VITE_TAPPD_APP_ID |
| Create React App | REACT_APP_TAPPD_APP_ID |
| Next.js | NEXT_PUBLIC_TAPPD_APP_ID |
| Generic Node.js | TAPPD_APP_ID |
Best practices
Next steps
API Reference
Explore every method available on the
TappdSDK instance.In-App Messages
Learn how to configure and display in-app messages.
Examples
See configuration options applied in real-world scenarios.