How to connect with MCP using a service key

More and more teams plug their dashboards into their own automations: an n8n pipeline that pulls the numbers every night, a script that feeds another tool. These automations talk to the MCP server with nobody in front of the screen, and a personal login is a poor fit for them.

A service key solves that. It is a credential that belongs to your account rather than to one of your users, so your pipeline has an identity of its own instead of borrowing someone else’s.

Why a service key rather than a normal login

Until now the only way to get access was an interactive sign-in, and the resulting token belonged to the person who signed in. That token expires after an hour and has to be renewed automatically, a mechanism designed for a human browsing rather than for a script running alone overnight.

A service key behaves differently:

• It belongs to the account. A password change or a sign-out by one of your users never affects it, and it keeps working after that person leaves your team.
• It is revocable on its own. Revoking one key leaves every other user and every other key untouched.
• You choose what it can do when you create it: read-only, or read and write.

Before you start

• This is self-serve. No ticket and no help from our Support Team is needed, to create a key or to revoke one.
• The secret is shown once. Have the secret manager your automation uses ready before you start.

Create a service key

1. Open My Account, then the Service Keys screen.
2. Name the key after the tool that will use it, for example “Nightly pipeline”, so you recognize it later in the list.
3. Choose its access: read-only, or read and write. Read and write lets the key create dashboards as well as read them, and it is never on by default.
4. Create the key. The secret appears once, at that moment, starting with dsk_. It exists nowhere else afterwards, not on the screen, not in our systems, and not in an email. If you lose it, create a new key.
5. Store the secret in your secret manager before closing the dialog.

Your key then appears in the list with its name, its access, the date you created it, and the date it was last used. The secret is never shown again, and you can revoke the key in one click at any time.

Exchange your key for an access token

Your automation sends the key to the DashThis token endpoint and receives an access token in return. It is the same endpoint the other flows use, with a dedicated grant_type, sent as application/x-www-form-urlencoded.

POST https://auth.dashthis.com/oauth/token Content-Type: application/x-www-form-urlencoded  grant_type=urn:dashthis:params:oauth:grant-type:service-key &service_key=dsk_your-secret-here &client_id=your-client-id

service_key carries the raw secret exactly as it was shown to you, dsk_ prefix included. It is not a client_secret and not a Bearer header, but a form parameter of its own.

The response is a standard OAuth token response:

{   "access_token": "...",   "token_type": "Bearer",   "expires_in": 3600 }

No refresh token is ever returned for this grant. The service key is itself the lasting credential, so your automation simply repeats this exchange on each run, or roughly every hour, rather than managing a separate renewal.

Call the MCP server

Send the access token as a bearer token to https://mcp.dashthis.com/mcp:

Authorization: Bearer <access_token>

The token carries the access you chose when you created the key: mcp:tools for reading, plus dashboards:write if you created the key with write access. The token identifies the service key itself rather than a user, so a dashboard created through a service key is attributed to that key in the dashboard history, not to a person.

If the exchange fails

Revoke a key

Open My Account → Service Keys, find the key in the list, and revoke it. It stops working immediately, and the other keys and users on your account are not affected. A key is also revoked automatically if the account is cancelled.

Good to know

• Treat a service key like a password. Never commit one to a public code repository, paste it into a chat channel, or send it by email.
• Use one key per pipeline rather than one key shared across several uses. That way you can revoke a single pipeline without breaking the others, and you can tell what is using what.
• If you suspect a key has leaked, revoke it right away from My Account and create a new one. You do not need to contact anyone to do it.
• Write access is opt-in. A key can create dashboards only if you chose read and write when you created it.
• For the full picture of what the MCP server can and cannot do, see MCP notes and limitations.

Need help with service keys?

Contact our Support Team here 💪🏼

What's next?

MCP notes/limitations

DashThis MCP Connector: How It Works and What You Need to Know