API Keys
Create, use and revoke publishable and secret keys, and keep them safe.
API keys connect your app and your servers to a Lander project. Open Settings, then API keys (G K), at /{org}/{project}/settings/api-keys. The page sums it up: "Publishable keys go in your app. Secret keys stay on your server."
Key kinds
Lander has two kinds of keys, and each exists separately for test and live. A key always belongs to one project and one environment, and the key alone decides both: your app and server never send a project ID.
| Kind | Prefix | Use it in | Can call |
|---|---|---|---|
| Publishable | pk_test_ or pk_live_ | The Flutter SDK, inside your app | The SDK endpoints (/v1/sdk/*): launch reports, resolving links, events, creating links from the app and claiming handoffs |
| Secret | sk_test_ or sk_live_ | Your server only | The management endpoints (/v1/links*, /v1/handoffs*, /v1/deferred/settings) and the SDK endpoints |
The dialog describes them as:
- Publishable: "For the Flutter SDK. Can resolve links and report events. Safe to ship."
- Secret: "For your server. Can create, change and delete links."
Calling an endpoint with the wrong kind of key fails with 403 wrong_key_kind. A missing, malformed, unknown or revoked key fails with 401 invalid_api_key.
Key format
A key is its prefix followed by a random string of letters and digits:
pk_live_3fK9...
sk_test_Q2x8...The first 12 characters (for example pk_live_3fK9) are the key's display prefix. That is all the dashboard ever shows after creation. Lander stores only a SHA-256 hash of the full key, so nobody, Lander included, can show it to you again.
Create a key
Pick the environment
Keys are created in the environment you are viewing. The page says which: "Showing test keys. Switch mode at the top to see the others." Use the Test / Live switch in the header to change it. See Environments.
Open the dialog
Click Create key. The dialog is titled New test key or New live key, for your project.
- Name: optional, up to 100 characters, for example "iOS and Android app" or "Backend". Left empty, a publishable key is named "SDK key" and a secret key "Server key".
- Kind: Publishable (selected by default) or Secret.
Click Create key.
Copy the key now
The next screen, Copy your key now, shows the full key once: "We only store a hash, so this is the only time you will see the full key." Click Copy, store the key where it belongs (see below), then click Done.
For a secret key, the dialog adds a warning: "Secret keys can create and delete links. Keep this one on your server, never in an app."
If you lose a key, you cannot recover it. Create a new one and revoke the old one.
With no keys in the current environment, the page shows "No test keys yet" (or live) with a Create publishable key button.
The keys table
| Column | Shows |
|---|---|
| Name | The key's name and a Publishable or Secret badge |
| Key | The display prefix, for example pk_live_3fK9… |
| Last used | When the key last made a request, or "Never". Updated at most once a minute. |
| Created | The creation date |
Active keys have a Revoke button. Revoked keys stay in the list, greyed out, with "Revoked" and how long ago. Some columns are hidden on narrow screens.
Revoke a key
Click Revoke on the key's row. The confirmation reads:
Revoke <name>?
Requests using <prefix>… start failing right away.
Apps already shipped with this key stop resolving links. This cannot be undone.(The middle sentence appears for publishable keys only.) Click Revoke key to confirm.
Requests with the key then fail with 401 invalid_api_key. The API remembers valid keys for up to 30 seconds per server, so a revoked key can keep working for a few seconds more. A revoked key cannot be restored.
Who can manage keys
Owners, admins and developers can see, create and revoke keys. Marketers see "API keys are managed by developers, admins and owners. Ask one of them for access." instead of the list.
Use your keys
In your Flutter app
Pass a publishable key to Lander.initialize. The SDK only accepts publishable keys and rejects secret ones.
await Lander.initialize(
apiKey: 'pk_live_...', // publishable key
);To keep test and live apart, you can pass the key in at build time instead of hard coding it:
const landerKey = String.fromEnvironment('LANDER_KEY');
await Lander.initialize(apiKey: landerKey);flutter run --dart-define=LANDER_KEY=pk_test_...
flutter build ipa --dart-define=LANDER_KEY=pk_live_...See Initialize for every option.
On your server
Send a secret key as a bearer token to https://api.golander.link:
POST /v1/links HTTP/1.1
Host: api.golander.link
Authorization: Bearer sk_live_...
Content-Type: application/json
{ "deepLinkPath": "/product/123", "title": "Product 123" }Links created this way land in the key's environment, on your project's default domain unless you pass another one.
Security guidance
Never ship a secret key
Anything inside an app binary is public: anyone can unpack it and read the strings. A secret key can create, change and delete every link in its environment. Keep secret keys on servers you control, and only ever put publishable keys in your app.
- Publishable keys are safe to ship, but not secret. They can only report launches and events, resolve links and create links from the app, all rate limited (300 requests per minute per key and client IP, and 20 app created links per minute per install). Treat them like a public identifier.
- Store secret keys like passwords. Put them in your server's environment variables or secrets manager. Never commit them to git, paste them in chat, or put them in client side code, including web frontends.
- Use test keys while developing. Test keys only touch test data, so a mistake in development never affects live links or analytics. Use live keys in release builds and production servers only.
- One key per use. Create separate secret keys for separate services (for example "Backend" and "CI"), so you can revoke one without breaking the others. Last used helps you spot keys nobody uses any more.
- Rotate secret keys without downtime. Create the new key, deploy it, check that the old key's Last used stops moving, then revoke the old key.
- Think before revoking a publishable key. Apps already installed keep the key they shipped with. Revoking it breaks link resolving and event reporting in every version that uses it, until users update. Only revoke a publishable key you must, for example one that was abused, and ship the new key in an app update first.
- If a secret key leaks, create a replacement, update your server, and revoke the leaked key straight away.