Skip to content

API Keys

API keys authenticate requests to KloudMate. You’ll use them for two jobs: sending telemetry into your workspace, and reading data back out through the KloudMate API or the MCP server. What a key can do comes down to its type, which you choose when you create it.

Find your keys under Settings → API Keys. The page lists every key in the workspace along with its type, note, and creation date. A key belongs to the workspace it’s created in, so create it in the workspace whose data you want to reach. Adding a key requires the Admin role.

KloudMate has three key types. Pick the one that matches what you’re building.

A User Key works for any KloudMate API operation and is tied to your account’s permissions — it can read whatever you can read. This is the key to use for the KloudMate MCP server, and for any script or service that queries your observability data through the API.

Pass it as a bearer token:

Authorization: Bearer YOUR_API_KEY

Because the key carries your access, treat it like a password. Anyone holding it can act as you in the workspace.

A Backend ingest key is for server-side telemetry. Your OpenTelemetry collectors, SDKs, and the KloudMate agent use it to ship logs, metrics, and traces. It bypasses CORS and puts no restriction on where data comes from, so keep it on your servers — never ship it in a browser or mobile app.

For OpenTelemetry (OTLP) exporters, pass it in the Authorization header:

exporters:
  otlp:
    endpoint: "https://otel.kloudmate.com:4317"
    headers:
      Authorization: "Bearer YOUR_API_KEY"

A Frontend ingest key is for telemetry sent straight from a browser or mobile app, such as Real-User Monitoring. Because the key ships in client code where anyone can read it, you must list the allowed hosts it can send from. Data from any other origin is rejected, which limits the damage if the key leaks.

  1. Go to Settings → API Keys and click Add New. (The button appears only if you have the Admin role.)

  2. Choose a Key Type — User Key, Ingest Key – Backend, or Ingest Key – Frontend. You can’t change the type after the key is created, so pick the one that fits.

  3. For a Frontend ingest key, add at least one allowed host. Include the protocol and port if there is one, for example https://app.example.com. Data sent from any other origin is rejected.

  4. Add a Note that says what the key is for — mcp-server, prod-otel-collector, rum-web. The list shows only the note, so make it recognizable.

  5. Click Submit.

The key is shown once, right after you create it:

Please copy and save the API key below as it will not be shown again.

Copy it then and store it somewhere safe — a secret manager, your client’s config, or a CI secret. There’s no way to retrieve it later; if you lose it, create a new one and delete the old.

You can edit or delete only the keys you created. Open the actions menu on a key’s row to find both.

  • Edit lets you change the note and, for a Frontend key, its allowed hosts. The key type is fixed once created.
  • Delete is permanent — this action cannot be undone. Any agent, collector, app, or MCP client using that key stops working the moment you delete it, so swap in a replacement first if the key is in active use.

Delete a key promptly if it’s exposed or no longer needed. That’s the way to cut off access for a key that’s been leaked.