Ingestion Tokens

Ingestion Tokens authenticate your applications and services when sending telemetry data to Last9. These tokens control what data can be sent and from which origins, ensuring secure data collection.

Creating Ingestion Tokens

1. Select Token Type:

   • Client: For client-based data collection (eg: RUM)
   • Prometheus Remote-Write: For server-side Prometheus-compatible metrics

2. Client Type (if Client selected):

   • Web Browser: browser RUM — allowlist https:// origins
   • Android / iOS: native mobile RUM — allowlist android://<package> or ios://<bundle-id>
   • React Native (Android) / React Native (iOS): React Native RUM — same android:// / ios:// origins; create one token per OS
   • Flutter (Android) / Flutter (iOS): Flutter RUM — same android:// / ios:// origins; create one token per OS

   All options create the same backend token type (client_monitoring). The platform choice only guides the origin format. See Android, iOS, React Native, and Flutter RUM docs for platform-specific setup.

3. Set Origins (for Client tokens):

   • For web apps, add the domains from which your application will send data — example: https://www.example.com
   • For mobile apps, use android://<package-name> or ios://<bundle-id> instead of a domain — example: android://com.acme.myapp
   • For React Native and Flutter apps, create separate Client tokens for Android and iOS (one origin per token) rather than combining both origins on one token
   • Multiple origins can be added to a single token for multi-domain web apps or other cases where one credential should cover several origins
   • Wildcard subdomains are supported for web origins using *. prefix (e.g., https://*.example.com) — not applicable to android:///ios:// origins, which must match exactly

   ✅ Correct Origins:
   https://app.example.com
   https://www.example.com
   http://localhost:3000
   https://*.example.com          (matches any single subdomain)
   https://*.apps.example.com     (matches subdomains of apps.example.com)
   https://app.*.example.com      (matches app.{any}.example.com)
   android://com.acme.myapp       (exact package name, no wildcards)
   ios://com.acme.myapp           (exact bundle ID, no wildcards)
   
   ❌ Incorrect Origins:
   example.com                    (missing protocol)
   app.example.com                (missing protocol)
   https://example.*              (TLD must be explicit, e.g., .com, .io)
   android://*                    (mobile origins must be an exact package name/bundle ID)

   Wildcard Origins

   Wildcard origins allow you to match multiple subdomains with a single entry. This is useful when:

   • Your application serves multiple customer subdomains (e.g., customer1.example.com, customer2.example.com)
   • You have dynamic environments that create subdomains on the fly
   • You want to simplify token management across many subdomains

   Wildcard Rules:

   Pattern	Matches	Does Not Match
   https://*.example.com	https://app.example.com, https://www.example.com	https://example.com, https://sub.app.example.com
   https://*.apps.example.com	https://prod.apps.example.com, https://dev.apps.example.com	https://apps.example.com
   https://app.*.example.com	https://app.staging.example.com, https://app.prod.example.com	https://app.example.com

4. Name Your Token:

   • Use a descriptive name to identify the token’s purpose
   • Example: “Production RUM Token” or “Staging Web Monitoring”

5. Click CREATE TOKEN to generate your token

Client Token Security

Is the Client Token Safe to Expose?

Yes. Client tokens are specifically designed to be visible in your frontend code and are safe to include in your application bundle.

Why Client Tokens Are Safe

• Write-Only Permissions: Client tokens can only send telemetry data to Last9. They cannot read, query, or access any data from your account.
• CORS-Restricted: Tokens are restricted to the origins (domains) you configure above, preventing unauthorized websites from using your token.
• No Account Access: Client tokens cannot access your Last9 account settings, billing information, or any other sensitive data.
• Designed for Public Use: This security model is standard across the industry for frontend monitoring.

Why Not Use API Keys?

API keys have full read/write access to your entire Last9 account and should never be exposed in frontend code. Client tokens exist specifically to provide a safe way to send telemetry from browsers.

Security Best Practices

While client tokens are safe to expose, follow these practices to minimize abuse:

1. Rotate Tokens Periodically: Rotate your client tokens every 90 days as a preventive measure.

2. Restrict CORS Origins: Configure allowed origins (as shown above) to only accept data from your domains.

3. Use Different Tokens Per Environment: Use separate tokens for development, staging, and production.

4. Monitor Usage: Regularly review your usage dashboard to detect unusual patterns or potential abuse.

Handling CI/CD Security Scanners

Your CI/CD pipeline security scanners may flag client tokens as secrets. This is a false positive. To resolve:

GitGuardian / GitHub Secret Scanning

Add an exception for client tokens:

# .gitguardian.yml
paths-ignore:
  - "**/*.html"
  - "**/rum-config.js"

allow-patterns:
  - "clientToken.*"
  - "L9RUM\\.init"

Inline Comment Exception

Add security scanner directives:

// gitguardian:ignore - Public client token with write-only permissions
// nosemgrep: generic.secrets.security.detected-generic-secret
const CLIENT_TOKEN = "your-token-here";

Troubleshooting

Please get in touch with us on Discord or Email if you have any questions.