Getting started
Authentication and API keys
Connect an SDK to the correct Deeplinkly project, find or generate its API key, and configure the key using the exact native setting each platform reads.
Jump to
The API key identifies the dashboard project that should receive the SDK's links, attribution, and events.
Your dashboard login uses a browser session. Mobile SDKs do not use that session and do not ask an end user to sign in to Deeplinkly. Instead, the app supplies one active project API key during SDK initialization. The native SDK attaches that project credential to its Deeplinkly API requests.
Use the key from the active project
The project selector in the dashboard controls which App Settings and API keys you are viewing. A key copied from another project sends data to that other project even if the app's package or bundle configuration is correct.
Keys are created and managed at the bottom of the selected project's App Settings page.
- Sign in to Deeplinkly and select the project you are integrating.
- Open Dashboard → App Settings.
- Scroll past the platform settings to the API Keys card.
- Copy an existing key whose status is Active, or choose Add API Key and confirm Generate API Key.
- Use Copy to copy the complete value. The eye control only changes whether the value is visibly masked in the dashboard.
Keep environments separate
Use separate active keys for development and production so you can rotate or disable one environment without interrupting the other. Give each release the key through its native build configuration rather than a runtime text field.
Android reads the project key from application metadata, then uses it when Deeplinkly initializes.
Add the exact metadata name below inside <application> in AndroidManifest.xml. Replace only the value.
<application ...>
<meta-data
android:name="com.deeplinkly.sdk.api_key"
android:value="your_api_key_here" />
</application>Initialize the SDK from your application class:
class App : Application() {
override fun onCreate() {
super.onCreate()
Deeplinkly.init(this)
}
}The metadata name is exact
com.deeplinkly.sdk.api_key is required. Environment-style names such as DEEPLINKLY_API_KEY are not read automatically.
Continue with the Android SDK guide.
<key>DeeplinklyApiKey</key>
<string>your_api_key_here</string>import Deeplinkly
Deeplinkly.initialize()Native iOS can also call Deeplinkly.initialize(apiKey:) when the build supplies the key programmatically. Initialization is idempotent and the first call wins, so choose one source and keep it consistent.
Continue with the iOS SDK guide.
- Android: add
com.deeplinkly.sdk.api_keytoandroid/app/src/main/AndroidManifest.xml. - iOS: add
DeeplinklyApiKeytoios/Runner/Info.plist.
After both native configurations are present, initialize the plugin once before listening for links:
import 'package:flutter/widgets.dart';
import 'package:flutter_deeplinkly/flutter_deeplinkly.dart';
void main() {
WidgetsFlutterBinding.ensureInitialized();
FlutterDeeplinkly.init();
runApp(const MyApp());
}Do not hard-code the key in Dart
FlutterDeeplinkly.init() takes no API-key argument. Each native platform reads its own packaged configuration.
Continue with the Flutter SDK guide.
React Native also reads the key from native configuration and does not expose a JavaScript initialization call.
- Android: add
com.deeplinkly.sdk.api_keyto the app manifest. - iOS: add
DeeplinklyApiKeyto the app's Info.plist. - Rebuild the native app after changing either file; a JavaScript reload is not enough.
During development, assert that the native module found its key:
import Deeplinkly from 'react-native-deeplinkly';
if (__DEV__ && !(await Deeplinkly.isAvailable())) {
console.warn('Deeplinkly: no API key in AndroidManifest.xml / Info.plist');
}Do not hard-code the key in JavaScript
There is no init(apiKey) call. Android and iOS initialize from their native files, and isAvailable() distinguishes a missing key from an ordinary network failure.
Continue with the React Native SDK guide.
- Confirm the key remains enabled in the selected project's API Keys card.
- Build and install a fresh native binary after changing manifest or plist values.
- Enable the SDK's debug logging only in development.
- Open a Deeplinkly test link on a device and confirm the resolved payload reaches the app.
- Check the same project in Deeplinkly for the resulting click, attribution, or event.
Authentication is working when
The SDK initializes with the key, a real device can resolve a link, and the activity appears under the same dashboard project from which you copied the key.
- Generate a second key in App Settings and leave the current key active.
- Update the native configuration in every supported platform build.
- Release and verify the new build against the correct project.
- After the migration window, disable the old key and monitor older app versions.
- Delete the old key only when you are certain no supported build still uses it.
Deleting a key is permanent
Disabling is safer during migration because it can be reversed from the dashboard. Deleting permanently revokes the key.
| Symptom | Check |
|---|---|
| SDK stays disabled or unavailable | Confirm the exact native key name, an Active dashboard key, and a fresh native rebuild. |
| Requests appear in the wrong project | Switch projects in the dashboard and compare the complete key value with the app's build configuration. |
| Debug works but release fails | Check the release manifest or plist after build-variable substitution and verify the release target includes it. |
| A newly rotated key fails | Keep the old key active, confirm the new value was copied completely, then test the new binary before disabling anything. |