API Access with M2M Credentials

For automated, non-interactive workflows, SeekOut provisions OAuth 2.0 machine-to-machine (M2M) credentials — a client ID and secret your service exchanges for a short-lived access token. SeekOut does not issue static API keys.

For everyday interactive use — SeekOut MCP inside Claude, ChatGPT, Cursor, or another AI assistant — the standard OAuth sign-in is simpler and recommended, and you don't need M2M credentials. But some environments make browser-based sign-in impractical. In those cases, SeekOut can provision a dedicated M2M credential that gives an automated workflow secure, scoped access to the MCP server.

When to Use M2M Credentials

M2M credentials are intended for non-interactive and automated use cases. Consider them when:

• You're running a CI/CD pipeline or scheduled job that calls SeekOut MCP with no human present to complete an OAuth sign-in.
• You're building a server-side integration where a backend service — not an individual user — makes MCP requests.
• You're deploying in a headless or non-interactive environment where opening a browser for authentication isn't feasible.
• You need a shared service-account identity for a team or system process rather than a named user.

How to Get M2M Credentials

M2M credentials are provisioned by SeekOut on request — they are not self-service. A SeekOut administrator creates a confidential OAuth client for your organization, configured with the permissions and rate limits your use case needs.

How to Authenticate

M2M uses the OAuth 2.0 client_credentials grant: exchange your client ID and secret for a short-lived bearer token, then send that token on each request to the MCP server.

1. Exchange your credentials for an access token

curl -X POST https://app.seekout.io/api/oauth/token \
  -d "grant_type=client_credentials" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "scope=mcp:tools" \
  -d "resource=https://seekout-search-mcp.seekout.io/tools"

The response contains a short-lived bearer token:

{
  "access_token": "<short-lived JWT>",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "<refresh token>",
  "scope": "mcp:tools"
}

2. Call the MCP server with the token

Authorization: Bearer <access_token>

For MCP clients that read a JSON config file, add the token as a custom header:

{
  "mcpServers": {
    "seekout-search": {
      "url": "https://seekout-search-mcp.seekout.io/tools",
      "headers": {
        "Authorization": "Bearer <access_token>"
      }
    }
  }
}

3. Get a fresh access token when it expires

Access tokens are short-lived (see expires_in), so a long-running integration needs a way to renew them. For machine-to-machine access the simplest approach is to just re-run the step 1 exchange — your service already holds the client secret, so it can mint a new access token at any time with no extra state to track. A common pattern is to request a token on startup and request another whenever a request returns 401 Unauthorized.

Optional: use the refresh token

The token response also includes a refresh_token, for OAuth client libraries that expect a standard refresh flow. You can trade it for a new access token instead of re-running the full exchange — scope and resource carry over automatically:

curl -X POST https://app.seekout.io/api/oauth/token \
  -d "grant_type=refresh_token" \
  -d "refresh_token=YOUR_REFRESH_TOKEN" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET"

Each refresh returns a new refresh_token (they rotate on use), so you'd need to persist the latest one. Because it still requires your client ID and secret, it offers little over simply re-running the exchange — for most M2M integrations, step 1 is simpler. Refresh tokens matter most in user-context OAuth flows, where re-authenticating would otherwise require a person to sign in again.

Security Best Practices

OAuth Sign-In vs. M2M: Choosing the Right Method