New Relic Authentication: Methods, Setup, and Security (2026)

Authentication overview

New Relic employs a multi-faceted approach to authentication, distinguishing between user login for the New Relic One platform and programmatic access for its various APIs. This separation ensures that human users manage their interface access separately from how applications and services submit data or query the observability platform. For programmatic interactions, New Relic primarily uses API keys, which serve as tokens to authorize requests against specific API endpoints. These keys grant varying levels of access, depending on their type and scope, enabling actions such as ingesting telemetry data, querying collected metrics, or managing account configurations.

The authentication mechanisms support a range of use cases, from configuring agents in application code to deploying custom integrations and automating administrative tasks. Each API key is designed with specific permissions to adhere to the principle of least privilege, minimizing potential security risks. For instance, an Ingest License Key is used by agents to send data to New Relic, while a User API Key (also known as a REST API key) is for managing account resources and querying data via the REST API. The NerdGraph API Key provides access to New Relic's GraphQL API for advanced querying and configuration tasks.

Supported authentication methods

New Relic supports several authentication methods tailored for different interaction types:

• API Keys: These are alphanumeric strings used to authenticate programmatic requests. New Relic categorizes them by their function:
• Ingest License Key: Used by New Relic agents (e.g., APM agents, Infrastructure agents) to send application and infrastructure data to the platform.
• User API Key (REST API Key): Grants access to New Relic's REST APIs for administrative tasks, querying data, and managing resources.
• NerdGraph API Key: Specifically for authenticating requests to the NerdGraph GraphQL API, allowing for complex data queries and platform configuration.
• Personal API Keys: A specific type of User API key that is created and managed directly by individual users for their personal scripts and integrations.
• OAuth 2.0: For certain integrations and third-party applications, New Relic supports OAuth 2.0 as an authorization framework. This allows applications to obtain limited access to a user's New Relic account without directly handling their credentials. While New Relic also uses OAuth for user login via Google and GitHub, its primary API access is key-based. The OAuth 2.0 specification is detailed by the IETF RFC 6749.
• SAML 2.0: For enterprise users, New Relic supports SAML 2.0-based Single Sign-On (SSO). This allows organizations to authenticate users against their existing identity provider, streamlining access management and enhancing security by centralizing user authentication.

Here's a comparison of common authentication methods for New Relic:

Getting your credentials

To obtain API keys for New Relic, follow these steps:

1. Log In to New Relic One: Access your New Relic account through the web interface.
2. Navigate to API Keys: From the New Relic One homepage, go to your account settings. The exact path may vary slightly but typically involves navigating to "API keys" or "API access" under your user or account management section.
3. Create New Key: Depending on the type of key you need (Ingest, User, NerdGraph), you will find options to generate a new key.
• For an Ingest License Key, it is usually displayed directly in your account settings or when configuring an agent.
• For User API Keys (REST) and NerdGraph API Keys, you will typically click a "Create a key" button, name your key, and define its permissions (e.g., read-only, read/write for specific categories).
4. Securely Store Your Key: Once generated, New Relic will display the key. Copy it immediately and store it in a secure location. New Relic generally only shows the full key once, so if you lose it, you may need to regenerate it.

For SAML 2.0 configuration, the process involves setting up an identity provider (IdP) integration within your New Relic account settings. This typically requires exchanging metadata with your IdP and configuring assertions to map user attributes correctly.

Authenticated request example

Here's an example of an authenticated request using a New Relic User API Key to query data via the New Relic REST API. This example uses curl to fetch a list of applications monitored by New Relic. Replace YOUR_API_KEY with your actual User API Key and YOUR_ACCOUNT_ID with your New Relic account ID.

curl -X GET 'https://api.newrelic.com/v2/applications.json' \
     -H 'X-Api-Key: YOUR_API_KEY' \
     -H 'Content-Type: application/json'

For the NerdGraph GraphQL API, the authentication header remains similar, but the request body contains the GraphQL query. This example fetches a list of entities (e.g., services, hosts).

curl -X POST 'https://api.newrelic.com/graphql' \
     -H 'Content-Type: application/json' \
     -H 'API-Key: YOUR_NERDGRAPH_API_KEY' \
     --data-raw '{ "query": "{ actor { entitySearch(query: \"type = \"SERVICE\"\") { results { entities { name domain type } } } } }" }'

When using New Relic agents, the Ingest License Key is typically configured in the agent's configuration file or as an environment variable, rather than being passed as a direct HTTP header.

Security best practices

Securely managing your New Relic credentials is vital to protect your observability data and prevent unauthorized access. Adhere to these best practices:

• Least Privilege: Create API keys with the minimum necessary permissions. If a key only needs to ingest data, use an Ingest License Key. If it needs to read metrics, ensure it doesn't have write access unless explicitly required.
• Key Rotation: Regularly rotate your API keys. New Relic allows you to generate new keys and revoke old ones. This practice limits the window of exposure if a key is compromised. The frequency of rotation should align with your organization's security policies.
• Secure Storage: Never hardcode API keys directly into source code. Instead, store them in secure environment variables, secret management services (e.g., AWS Secrets Manager, HashiCorp Vault), or configuration files with restricted access. Ensure these storage locations are protected against unauthorized access. The Google Cloud security checklist recommends similar practices for API keys.
• Restrict Access: Limit who has access to generate, view, or manage API keys within your New Relic account. Use New Relic's user roles and permissions to enforce appropriate access controls.
• Monitor Usage: Regularly review audit logs and API key usage within New Relic to detect any anomalous activity. Unusual spikes in API calls or access from unexpected IP addresses could indicate a compromised key.
• Use Environment Variables: For application deployments, pass API keys as environment variables rather than embedding them in deployment artifacts. This prevents keys from being exposed in version control systems or build logs.
• IP Whitelisting (where available): If your use case supports it, restrict API key usage to specific IP addresses or ranges. This adds a layer of network-level security, ensuring that even if a key is stolen, it cannot be used from an unauthorized network location.
• TLS/SSL Encryption: Always ensure that all communication with New Relic APIs occurs over HTTPS (TLS/SSL) to protect credentials and data in transit. New Relic API endpoints enforce TLS encryption.
• Delete Unused Keys: Periodically audit your API keys and delete any that are no longer in use. This reduces the attack surface and simplifies key management.