Bearer key on POST /api

Authentication is one header. Official docs: Authorization: Bearer <api_key>. The request is POST https://api.trendsapi.ai/api with Content-Type: application/json. The key is not a query parameter and not a field inside the JSON body. A missing or wrong header returns 401. Get a key from the key form. This page does not quote plan prices. Those sit on pricing. The same Bearer header authenticates https://api.trendsapi.ai/mcp.

The header

POST https://api.trendsapi.ai/api
Authorization: Bearer <api_key>
Content-Type: application/json

{"mode":"get_time_series","source":"google search","keyword":"bitcoin"}

mode, source, and keyword are body fields. The key is not. A body field named api_key is ignored. A missing header is 401, documented on errors.

Strip whitespace from the token. Do not wrap the token in extra quotes inside the header value. Bearer has a single space before the key. A leading or trailing newline in the secret is a 401 that looks like a mode bug.

Where the key goes

Server-side cron, a backend route, or an official SDK constructor. Official docs say not to ship the key in frontend code or a public repository. Rotate a leaked key from the account page.

The envelope after a 200 still needs a second parse. That step is not auth. It is on parse the body.

MCP uses the same Bearer

{
  "mcpServers": {
    "trends-api": {
      "url": "https://api.trendsapi.ai/mcp",
      "headers": {"Authorization": "Bearer YOUR_API_KEY"}
    }
  }
}

That block is the documented MCP config. The agent then calls get_time_series, get_growth, or get_top_trends. It does not send a second key. OAuth discovery on the connector is a different flow for hosts that speak MCP OAuth. A raw REST cron still uses the Bearer header above.