Connecting to NewRelic

Connect your New Relic account to OneLens for cost intelligence, ingest and seat cost attribution, sub-account cost allocation, and budget and anomaly alerting, using a dedicated read-only integration user and New Relic's own consumption data.

How New Relic cost works here, read this first. New Relic's API returns billable quantities, not dollars. The estimatedCost attribute was deprecated in May 2022, and no New Relic API exposes your contract rates. OneLens therefore combines New Relic's own billable metrics with a rate card you provide, so how closely your reported cost matches your invoice depends on those rates being right and current. See How It Works before you build a chargeback model on it.

TL;DR

• What this does: Reads billable consumption from New Relic's usage events via NerdGraph, applies your contract rates, and reports New Relic spend next to AWS, GCP, Azure, and OCI in OneLens.

• Time required: ~20 minutes, most of it gathering your rate card.

• Who you need: Someone who can create users in New Relic and view Administration → Usage Summary, plus whoever holds your New Relic contract or order form for the pricing.

• What OneLens reads: New Relic's usage events (NrMTDConsumption, NrConsumption, NrDailyUsage) through a dedicated integration user. Read the honest caveat in Security at a Glance about what a New Relic User key can technically reach.

Before You Start: What You Need to Know

Three things about New Relic shape this integration, and it is better to know them now than at step 4.

Fact	What it means for you
New Relic exposes usage, not cost. estimatedCost was deprecated in May 2022	You supply your contract rates. OneLens computes cost from New Relic's billable quantities and your rates. Every cost figure is modelled, not billed
New Relic has no scoped API keys. A User key inherits the account permissions of the user who created it, and carries no per-key permission scope	You create a dedicated integration user and control exposure by which accounts you grant it. Log partitions can be restricted further on Pro and Enterprise; see Security at a Glance
The integration user can be a free Basic user	The integration adds no seat cost. New Relic states plainly that "all users can query all data in the accounts they can access" and that "Basic users are free"

Free tier: New Relic gives you "access to 100 GB Ingested per month for free." OneLens prices the *Billable attributes rather than raw consumed quantities, and cross-checks the result against your Usage Summary page at connect time, so free usage is not priced as cost. New Relic reports free and billable consumption separately on some events, so step 3 includes that cross-check rather than assuming the arithmetic.

What You'll Get Once Connected

Capability	What it does for you
Unified Cost Explorer	New Relic spend sits next to your AWS, GCP, Azure, and OCI cost in one view, on the same date and currency basis
Ingest Cost Breakdown	Billable GB by consuming account and product line, so you can see which telemetry stream is driving the bill
Seat Cost Breakdown	Billable Full Platform and Core user counts over time, separated from data cost, so a seat creep problem is distinguishable from an ingest problem
Sub-Account Attribution	New Relic tags usage with consumingAccountId, so spend attributes to the account that generated it without you tagging anything
Anomaly Detection	Alerts when billable ingest or seat count breaks its own pattern, so you catch a runaway log source inside the month
Budget Tracking	Set New Relic budgets with OneLens alerting, on data cost, seat cost, or the total
Multi-Account Reporting	One integration user covers every account it is granted, and OneLens reports across all of them in one currency

Security at a Glance

New Relic's key model is weaker than most, and pretending otherwise would not survive your security review. The important row is the third one.

Question	Answer
What authentication is used?	A User key (format NRAK-...) created by a dedicated integration user, sent in the API-Key header to NerdGraph.
Is the key read-only?	In practice, for our use, yes. OneLens issues only NRQL read queries against usage events. But see the next row: New Relic does not offer a key you can technically restrict.
Can the key be scoped to billing data only?	No, and this is the honest limitation. New Relic has no scoped or permission-restricted API keys. A User key inherits the account permissions of the user who created it. That means a key which can read your usage events can also query telemetry in the same accounts. OneLens's restriction to usage events is a contractual and audit commitment, not something New Relic's key model enforces.
So how do we limit exposure?	Primarily by account. You create a dedicated integration user and grant it only the accounts OneLens needs. New Relic's guidance notes you "don't need to use your Admin-level access for the integration" and that you can "assign only the accounts that you want to expose to the integration."
Is there anything finer-grained?	Yes, for logs. New Relic's Data access control lets you create policies restricting access to specific log partitions, and those policies do bind user keys. It covers log data only and requires Pro or Enterprise. If your sensitive data is in logs, this is a real additional control worth applying to the integration user. It does not restrict metrics, traces, or events.
Does OneLens read our application data, logs, or traces?	No. OneLens queries NrMTDConsumption, NrConsumption, and NrDailyUsage, which contain consumption counters only. We maintain an audit log of every query issued against your account, available on request.
Can OneLens change anything in New Relic?	No. OneLens issues NRQL read queries. It does not call NerdGraph mutations, so it cannot create users, change alerts, modify configuration, or delete data.
Can OneLens see our billing or payment details?	No. Usage events carry consumption counters. Your invoices, payment method, and contract documents are not exposed by these queries.
What happens if the integration user is deleted?	Its keys stop working. New Relic states that when a user is deleted, "their user keys are also deactivated and won't work." That is also your fastest revocation path.
Is the key tied to an employee?	No, and that is the point of the dedicated user. A key created by a real person deactivates when that person leaves, silently breaking the integration. A dedicated integration user has no such dependency.
How is data transmitted and stored?	All calls use HTTPS/TLS 1.2+. The key is encrypted at rest in OneLens using GCP KMS.
What is the data retention policy?	OneLens retains ingested data for 12 months by default, configurable. On disconnection or a deletion request, data is purged within 30 days with confirmation.
Where does the data live?	OneLens infrastructure runs on GCP. See the OneLens Trust & Security page for region details, SOC 2 report, and DPA.

Cost of the Integration

OneLens deploys nothing into New Relic and the integration user is free. There is one caveat, and it applies only to some pricing models.

Item	What it is	Typical cost
Integration user seat	A Basic user. New Relic states "Basic users are free"	$0
NerdGraph API calls	A handful of NRQL queries per day	$0 on Data + User pricing
Compute Capacity Units	On Core Compute and Advanced Compute pricing only. New Relic measures those models in CCUs consumed by queries, alerts, API calls, and page loads, so OneLens's daily queries consume a small number	Negligible but not zero. See the note below
Data ingest	None. OneLens sends nothing to New Relic, so it adds no billable GB	$0
Storage in your account	None. OneLens stores ingested data in its own infrastructure	$0
Estimated total	Sum of the above	$0/month on Data + User. On CCU-based models, the cost of a few queries a day

On the CCU caveat. If you are on Data + Core Compute or have the Advanced Compute add-on, API calls consume CCUs, and New Relic notes that even free Basic users "can drive billing for usage-based features including the Advanced Compute add-on." OneLens runs a small fixed number of queries per day rather than polling, so the consumption is tiny, but we would rather name it than let you discover it. Tell us if you want the query count minimised and we will reduce cadence.

How It Works

New Relic reports your own consumption back to you as queryable events inside your account. OneLens reads those events through NerdGraph, New Relic's GraphQL API, and applies your contract rates to turn quantities into cost.

The events OneLens uses:

Event	What it holds	Why OneLens reads it
NrMTDConsumption	Month-to-date aggregates, including GigabytesIngestedBillable, FullPlatformUsersBillable, and CoreUsersBillable	The primary source. These are the billable quantities, which is what your rates apply to
NrConsumption	Hourly consumption, including GigabytesIngested by productLine and consumingAccountId	Trend and attribution detail, and the basis for anomaly detection inside a month
NrDailyUsage	Daily breakdown, with synthetics detail facetable by monitor and location	Synthetic check volume, which is priced separately on many contracts

Why you supply the rate card

This is the part that differs from most OneLens integrations, and it is worth understanding before you rely on the numbers.

New Relic used to expose an estimatedCost attribute on its usage events. It was deprecated in May 2022, and New Relic now directs you to query consumption quantities instead. No New Relic API returns your negotiated per-GB rate, your per-user rates, your committed volume, or your tiered discounts. Those live in your contract, which is why the rate card has to come from you.

So OneLens computes:

billable quantity (from New Relic)  ×  your rate (from your contract)  =  cost

Every other cost platform connecting to New Relic works the same way, because there is no alternative. What matters is being clear about what that produces:

New Relic cost in OneLens is a modelled figure, not a billed one. It reconciles to your invoice when the rate card is accurate and current. It will diverge if your contract changed mid-period, if you have tiered rates we were not told about, or if a commitment true-up lands outside the usage data. OneLens labels these figures as rate-card derived, and if your agreement changes, tell us so we can restate rather than quietly carrying stale rates forward.

The quantities themselves are not estimates. GigabytesIngestedBillable and the billable user counts are New Relic's own billing metrics, the same numbers behind your invoice. The modelling risk lives entirely in the rates.

What granularity you get

Cost breaks down by consuming account, by product line, and by charge type (data ingest, Full Platform seats, Core seats, synthetic checks). New Relic stamps usage with consumingAccountId, so sub-account attribution needs no tagging work from you.

There is no per-service or per-application cost dimension in the usage events. If you need New Relic spend attributed to a team or service below the account level, the practical route is to structure sub-accounts along the lines you want to charge back, since that is the boundary New Relic itself reports on.

What OneLens Will Access

Item	Detail
Endpoint	https://api.newrelic.com/graphql for US accounts, https://api.eu.newrelic.com/graphql for EU, https://api.jp.newrelic.com/graphql for Japan
Auth header	API-Key: <YOUR_USER_KEY>
Queries	NRQL SELECT statements against NrMTDConsumption, NrConsumption, and NrDailyUsage
Accounts	Only those you grant the integration user
Mutations	None. OneLens issues no NerdGraph mutations of any kind

What OneLens Will NOT Access

• ❌ Your telemetry. No APM traces, no logs, no browser or mobile events, no infrastructure metrics, no custom events. See the honest caveat above: this is our commitment and our audit log, not a technical restriction New Relic provides

• ❌ Dashboards, alerts, or workflows. OneLens does not read or modify them

• ❌ NerdGraph mutations. No user creation, no configuration change, no data deletion

• ❌ Accounts you did not grant. The integration user reaches only the accounts you assign it

• ❌ Your invoices, payment method, or contract documents

• ❌ License, Ingest, Browser, or Mobile keys. OneLens needs none of them and will refuse them if offered

Prerequisites

• A New Relic account on a paid plan. The free tier has no billable consumption to report.

• Permission to create a user in your New Relic organization and assign account access.

• Access to Administration → Usage Summary, to sanity-check what OneLens reports against what New Relic shows you.

• Your New Relic contract or order form, for the rate card in step 4. This is usually the slowest part, so start it early.

• curl and jq on the machine you run the validation calls from.

Validate and Connect

1

Create a Dedicated Integration User

Do not use your own account. New Relic makes the case for a dedicated user directly: "A big advantage of this is that you don't need to use your Admin-level access for the integration," and "all you have to do is create the new user and assign only the accounts that you want to expose to the integration."

1. In New Relic, go to Administration → User management.

2. Add a user with a traceable name, such as onelens-cost-integration, on an address your team controls rather than a personal mailbox. A shared alias or group address works well, since the key deactivates if the user is deleted.

3. Set the user type to Basic. Basic users are free and can still run every query this integration needs, because New Relic grants all users the ability to "query all data in the accounts they can access."

4. Grant account access deliberately. Assign the parent account if your organization uses a parent-child structure and you want usage for all sub-accounts, and add individual accounts only where you need them. Account assignment is your main exposure control, so treat it as the security decision it is.

5. If your sensitive data is in logs and you are on Pro or Enterprise, also apply a Data access control policy to this user. It restricts which log partitions a user can read, it binds user keys, and it is the one within-account restriction New Relic offers. It does not cover metrics, traces, or events.

Why the parent account, and when it applies. Usage events carry a consumingAccountId, and New Relic's guidance is that if you have a parent account structure, you should "run queries in a parent account to see the aggregated usage for that parent and its child accounts." So on a parent-child organization, one grant gives full cost coverage while keeping readable telemetry to a single account, usually the one holding the least.

This depends on your organization actually having that structure. Not every New Relic organization does, and the guidance is filed under New Relic's original account structure. The first query in the next step verifies it for your setup before you rely on it. If it comes back with only the parent, grant the accounts you need individually instead.

2

Create the User Key

Do this while signed in as the integration user, or create the key on that user's behalf as an admin. A key created under your own login inherits your access, not the integration user's, which defeats the previous step.

1. Open the API keys page from the user menu, or go straight to one.newrelic.com/api-keys. It is not nested under Administration.

2. Select Create a key, and choose User key.

3. Set the account and give it a name such as onelens-cost-integration.

4. Copy the key immediately. It begins with NRAK-.

Confirm the key belongs to the user you intended, which is the single most common setup mistake here:

export NR_USER_KEY="NRAK-your_key_here"
export NR_REGION_URL="https://api.newrelic.com/graphql"   # api.eu. or api.jp. for those regions

curl -s "$NR_REGION_URL" \
  -H "API-Key: $NR_USER_KEY" \
  -H 'Content-Type: application/json' \
  --data '{"query":"{ actor { user { name email } } }"}' | jq

The name and email that come back must be the integration user. If they are yours, the key was created under your login and you should delete it and try again.

Now list what the key can actually reach:

curl -s "$NR_REGION_URL" \
  -H "API-Key: $NR_USER_KEY" \
  -H 'Content-Type: application/json' \
  --data '{"query":"{ actor { accounts { id name } } }"}' | jq -r '.data.actor.accounts[] | "\(.id)\t\(.name)"'

Check this list against what you intended to grant. Anything unexpected on it is readable by this key, so fix the user's account access now rather than later.

3

Validate the Usage Data

Three queries. The first proves cost data exists, the second proves sub-account attribution works, the third proves you can separate data cost from seat cost.

Set your parent account ID first:

export NR_ACCOUNT_ID="your_numeric_account_id"

A. Ingest by consuming account

This is the query that confirms the parent-account approach covers your children. It uses NrConsumption, which is the event New Relic documents consumingAccountId against:

NRQL='SELECT sum(GigabytesIngested) FROM NrConsumption FACET consumingAccountId SINCE 2 months ago'

curl -s "$NR_REGION_URL" \
  -H "API-Key: $NR_USER_KEY" \
  -H 'Content-Type: application/json' \
  --data "$(jq -n --arg nrql "$NRQL" --arg acct "$NR_ACCOUNT_ID" \
    '{query: "{ actor { account(id: \($acct)) { nrql(query: \"\($nrql)\") { results } } } }"}')" \
  | jq '.data.actor.account.nrql.results'

You should get one row per consuming account. If you only get the parent, your sub-accounts are not visible from here and you will need to grant the integration user access to them individually.

B. Billable totals

These are the quantities your invoice is built on. New Relic documents latest() rather than sum() for month-to-date attributes, since they are running aggregates:

NRQL='SELECT latest(GigabytesIngestedBillable), latest(FullPlatformUsersBillable), latest(CoreUsersBillable) FROM NrMTDConsumption SINCE 1 month ago'

curl -s "$NR_REGION_URL" \
  -H "API-Key: $NR_USER_KEY" \
  -H 'Content-Type: application/json' \
  --data "$(jq -n --arg nrql "$NRQL" --arg acct "$NR_ACCOUNT_ID" \
    '{query: "{ actor { account(id: \($acct)) { nrql(query: \"\($nrql)\") { results } } } }"}')" \
  | jq '.data.actor.account.nrql.results'

C. Ingest by product line

This confirms consumption is attributable to the right categories:

NRQL='SELECT sum(GigabytesIngested) FROM NrConsumption FACET productLine SINCE 1 month ago'

curl -s "$NR_REGION_URL" \
  -H "API-Key: $NR_USER_KEY" \
  -H 'Content-Type: application/json' \
  --data "$(jq -n --arg nrql "$NRQL" --arg acct "$NR_ACCOUNT_ID" \
    '{query: "{ actor { account(id: \($acct)) { nrql(query: \"\($nrql)\") { results } } } }"}')" \
  | jq '.data.actor.account.nrql.results'

What to check:

Check	What good looks like
No errors key in the response	An errors block usually means the key lacks access to that account ID
Query A returns multiple accounts	Confirms sub-account attribution works from the parent. One row means it does not, or that your organization does not use a parent-child structure
Billable GB is non-zero	Zero across a full month usually means your consumption sat inside the free allowance, so there is no data cost to report yet. Seat cost may still be non-zero
User counts look right	Compare against Administration → Usage Summary. They should agree
productLine values appear	Expect values such as DataPlatform, FullStackObservability, and ProactiveDetection

Cross-check before you move on. Open Administration → Usage Summary in New Relic and compare its figures to what these queries returned. If they disagree, resolve that now. Every cost number OneLens produces is built on these quantities, so an error here propagates into everything downstream.

4

Gather Your Rate Card

This is the step that decides whether your OneLens New Relic cost matches your invoice, and it is the one that usually takes longest, because the numbers live in a contract rather than a UI.

New Relic's own surfaces will tell you which pricing model you are on. Administration → Usage Summary shows what you consume, and Administration → Consumption Management shows how it is being counted. The rates are not in the product at all, so the numbers below come from your order form, contract, or your New Relic account team. Collect:

Item	Why it is needed
Pricing model	Data + User, Data + Core Compute, or Advanced Compute. This determines what OneLens prices at all
Subscription term start and end date	Anchors commitments and lets OneLens apply the right rates to the right period
Per-GB ingest rate	The main data cost driver. Note separately if you are on Data Plus, which is priced differently from Original Data
Free ingest allowance	100 GB per month is standard, but confirm yours, since negotiated agreements vary
Per-user rates	Separate rates for Full Platform and Core users. Basic is free
Free user seats	Many contracts include a number of Full Platform seats before per-seat charges begin
Synthetic check pricing	Priced per check on many contracts, and reported separately in NrDailyUsage
Tiered or volume pricing	If your per-GB rate steps down above a threshold, give us the tiers rather than a blended average, or the model will be wrong at both ends
Committed volume or spend	So OneLens can show consumption against commitment rather than just raw spend
Currency	Your invoicing currency

Tell us when your contract changes. OneLens carries the rates you give us until you say otherwise. A renewal at new rates, with no word from you, produces cost figures that look plausible and are wrong. When your agreement changes, send us the new rate card and the effective date, and we will restate the affected periods rather than leaving a silent discontinuity in your history.

5

Connect to OneLens

Provide the following, either through the OneLens dashboard or by emailing [e-mail].

Field	Value	Example
User key	The NRAK- key from step 2. Share securely, see note below	NRAK-...
Parent Account ID	The numeric account ID you validated against	1234567
Region	US, EU, or Japan, which decides the endpoint	US
Rate card	Everything from step 4	See step 4 table

Share the key securely. Never send a NRAK- key over email or chat. Use a validated secure sharing tool such as Password.link.

What OneLens does next:

1. Confirms the key resolves to the integration user, not a person, and tells you if it does not.

2. Lists the accounts the key can reach and sends you that list. Check it. It is both your coverage confirmation and your exposure confirmation.

3. Pulls the usage history New Relic still holds for your account and tells you the earliest period it actually received.

4. Applies your rate card and begins daily ingestion.

Verification. Once OneLens confirms the connection, typically within 24 hours, check the OneLens dashboard for:

• New Relic appearing as a cost source with a non-zero total for the last closed month

• Data cost and seat cost shown separately, both non-zero if your contract has both

• Every consuming account you expected, and none you did not

• A total within a few percent of your last New Relic invoice. If it is out by more than that, the rate card is the first thing to re-check

Data Refresh Schedule

• Usage data is pulled once daily. New Relic updates the usage UI daily, so a faster cadence returns the same numbers while consuming more CCUs on compute-based pricing.

• Month-to-date figures move throughout the month as NrMTDConsumption accumulates. Treat the current month as provisional until the billing period closes.

• Rate card changes only when you tell us. There is no API to detect a contract change, so this one depends on you.

• Account list is re-read weekly, so a sub-account you grant later is picked up without a new key.

New Relic bills users on the highest user type assigned during the calendar month, even if the assignment was brief. So a seat temporarily upgraded and downgraded still bills at the higher type, and OneLens reports it that way because New Relic charges it that way.

Data Privacy & Security

• Usage events only. OneLens queries NrMTDConsumption, NrConsumption, and NrDailyUsage, which hold consumption counters rather than telemetry.

• Read queries only. No NerdGraph mutations, so nothing in New Relic can be created, changed, or deleted.

• Dedicated integration user. Not tied to an employee, so no departure silently breaks or extends access.

• Exposure limited by account grant. Your main control, and the reason step 1 matters more than it looks.

• Log partitions can be restricted further. New Relic's Data access control binds user keys and can limit which log partitions the integration user reads, on Pro and Enterprise plans.

• A stated limitation, not a hidden one. New Relic has no scoped keys, so our restriction to usage events is contractual and auditable rather than technically enforced. We keep an audit log of every query issued against your account and provide it on request.

• No agent, no ingest. Nothing is installed, and OneLens sends no data into New Relic, so it adds no billable GB.

• Simple revocation. Deleting the integration user deactivates its keys, and deleting a single key stops that credential alone.

• TLS in transit. All calls use HTTPS/TLS 1.2+.

• Encrypted at rest. The key and ingested data are encrypted at rest using GCP KMS.

• Data retention. 12-month default, configurable. Deletion within 30 days on request, with confirmation.

Troubleshooting

#	Symptom	Cause	Fix
1	The actor { user } query returns your name, not the integration user's	The key was created while signed in as you, so it carries your permissions	Delete the key. Recreate it as the integration user, or as an admin acting on that user's behalf
2	errors block saying the account is not accessible	The integration user has not been granted that account	Add the account to the user in Administration → User management
3	Query A returns only the parent account	Either your organization does not use a parent-child account structure, or sub-account usage is not visible from the parent	Confirm your structure first. New Relic's guidance to run usage queries in a parent account applies to parent-child organizations. If yours is not one, grant the integration user access to each account you need and re-run query A
4	Billable GB is zero for a full month	Your consumption sat inside the free allowance	Usually expected rather than an error. Cross-check against Usage Summary: if that page shows billable ingest and the query does not, tell us before connecting
5	User counts disagree with Usage Summary	NrMTDConsumption reports month-to-date, and the UI may be showing a different window	Align the query window to the billing month. If they still differ, raise it with us before connecting
6	NrDailyUsage figures do not match NrMTDConsumption	New Relic documents that NrDailyUsage results "may not match" the usage UI or NrMTDConsumption	Expected. OneLens treats NrMTDConsumption as authoritative and uses NrDailyUsage only for synthetics detail
7	429 Too Many Requests	NerdGraph allows 25 concurrent requests per user, and the limit counts all keys belonging to that user together	Rare for us, since OneLens runs a few sequential queries. If you see it, something else is using the integration user's keys concurrently
8	OneLens total does not match the invoice	Almost always the rate card: a tier we were not given, a changed contract, or a blended rate standing in for tiers	Re-check step 4 against your order form. Send us the corrected rates and the effective date and we will restate
9	Cost history has a step change at a date nothing happened	A contract change we were not told about, applied to the whole history	Send us the old and new rates with the effective date so the periods are priced correctly
10	Key stopped working	The integration user was deleted or deactivated, which deactivates its keys	Recreate the user and key. This is also the intended revocation path, so check whether someone removed it deliberately
11	No per-service cost breakdown	New Relic's usage events carry no service or application dimension	Working as intended. Attribution below account level means structuring sub-accounts along your chargeback lines

Frequently Asked Questions

Can OneLens read our application data, logs, or traces?

OneLens does not, and we will be precise about why rather than overclaim.

What we do: issue NRQL read queries against NrMTDConsumption, NrConsumption, and NrDailyUsage. Those events hold consumption counters, not telemetry. We keep an audit log of every query issued against your account and provide it on request.

What we cannot claim: that New Relic stops us. New Relic has no scoped API keys, so a User key able to read usage events in an account can also query telemetry in that same account. Our restriction is contractual and auditable, not technically enforced.

If that distinction matters to your security team, there are two levers. Account access is the main one: grant the integration user only the accounts OneLens needs, and the technically-reachable surface shrinks to those. Second, if your sensitive data is in logs and you are on Pro or Enterprise, New Relic's Data access control can restrict which log partitions this user reads, and those policies do apply to user keys. It covers logs only, not metrics, traces, or events.

Why do we have to give you our pricing? Doesn't the API have costs?

It used to, and New Relic removed it. The estimatedCost attribute on usage events was deprecated in May 2022, and the guidance since then is to query consumption quantities instead. No New Relic API returns your negotiated per-GB rate, per-user rates, committed volume, or tiered discounts, because those live in your contract rather than in the platform.

Every cost platform that connects to New Relic asks for the same thing, for the same reason. What OneLens does differently is label the result clearly as rate-card derived, so nobody mistakes a modelled figure for an invoice line.

How accurate will the cost figures be?

The quantities are exact. GigabytesIngestedBillable and the billable user counts are New Relic's own billing metrics, the same numbers behind your invoice.

The rates are as accurate as what you give us. With a complete rate card, including tiers rather than a blended average, expect to land within a few percent of the invoice, with the remainder usually being mid-period changes or true-ups.

It will be wrong if your contract changed and we were not told, if tiered rates were given as a single number, or if a commitment true-up lands outside the usage data. The first is the most common and the easiest to prevent: send us the new rate card and effective date whenever your agreement changes.

Does the integration user cost us a seat?

No. Set it to Basic, which New Relic states is free, and it can still run every query this integration needs, because New Relic grants all users the ability to "query all data in the accounts they can access."

One caveat if you are on Data + Core Compute or have the Advanced Compute add-on: those models are measured in Compute Capacity Units consumed by queries, alerts, API calls, and page loads, so our daily queries consume a small number. New Relic notes that free Basic users "can drive billing for usage-based features" this way. It is a handful of queries a day, and we will cut the cadence if you would rather.

Why a dedicated user instead of just using an admin's key?

Because a New Relic User key is tied to the person who created it and inherits their access. Two consequences follow. An admin's key can reach everything that admin can reach, which is usually far more than a cost integration needs. And when that person changes role or leaves, New Relic deactivates their keys, so the integration breaks with no warning beyond a cost report going flat.

A dedicated user fixes both, and New Relic makes the same case: "A big advantage of this is that you don't need to use your Admin-level access for the integration."

The Basic user type is our recommendation rather than New Relic's. Their integration guidance does not name a user type; we suggest Basic because New Relic's user-type documentation confirms Basic users are free and can still query all data in accounts they can access.

Use a shared team address rather than a personal mailbox, since the key stops working if the user is deleted.

Can we connect multiple New Relic accounts?

Yes, and usually with one key. A User key can query any account its owning user has been granted, so granting the integration user your parent account is often enough to cover every sub-account, with usage attributed by consumingAccountId.

Step 3's first query is what proves it for your structure. If it returns only the parent, grant the sub-accounts individually and re-run it.

If your accounts sit in separate New Relic organizations, they need one integration user and key each.

Can we attribute New Relic cost to a team or service?

Down to the account, yes, and that needs no work from you: New Relic stamps usage with consumingAccountId, and OneLens reports against it. You can group accounts into cost centres in OneLens on top of that.

Below the account, no. The usage events carry no service or application dimension, so there is nothing to attribute from. Organizations that need service-level New Relic chargeback generally structure sub-accounts along the lines they want to charge back, because that is the boundary New Relic reports on. Worth knowing before you design a chargeback model around it.

Will this impact our New Relic performance or hit our limits?

Performance, no. These are read queries against your usage events, nothing in your telemetry pipeline.

Limits, effectively no. NerdGraph limits concurrency rather than request rate, at 25 concurrent requests per user, and OneLens runs a few sequential queries a day. Because the limit counts per user rather than per key, the dedicated integration user also means our queries never contend with your engineers' dashboards or your own automation.

What about the 100 GB free allowance?

OneLens prices the *Billable attributes rather than raw consumed quantities, so free usage is not charged in your reported cost.

Two practical notes. New Relic reports free and billable consumption as separate attributes on some usage events, so step 3's cross-check against your Usage Summary page exists to confirm the numbers agree before you rely on them. And confirm your own allowance in step 4, because 100 GB per month is the standard figure but negotiated agreements vary.

How do I rotate the key?

Create a second User key under the same integration user, send it to OneLens securely, confirm ingestion continues on the next daily pull, then delete the old key on the API keys page. Overlapping them means no ingestion gap.

Do not delete the integration user to rotate a key. That deactivates every key it owns at once and requires rebuilding the account grants.

How do I disconnect OneLens?

Delete the User key on the API keys page, or delete the integration user, which deactivates all of its keys. Either way ingestion stops on the next attempted pull, and you do not need OneLens to act.

Historical data already ingested remains in OneLens until you request deletion, which is completed within 30 days with confirmation.

How far back can you backfill?

As far as New Relic still holds the usage events for your account. New Relic does not publish a retention period for its internal usage events, so rather than promise a number, OneLens pulls whatever history is available and tells you the earliest period it actually received.

From connection onward, OneLens persists every daily pull, so your history grows forward regardless of how deep the initial backfill reached.

Need Help?

New Relic official docs:

• How New Relic pricing works, covering the pricing models and billable components

• Query and alert on usage data, the reference for the usage events and their attributes

• Usage UI, for cross-checking what OneLens reports

• Best practices for integration users

• New Relic API keys, on key types and what User keys carry

• User type: basic, core, and full platform users

• User count and billing, on the highest-user-type rule

• Data access control, for restricting log partition access

• Introduction to NerdGraph, including regional endpoints

• NerdGraph usage limits

• Data ingest billing, on GB ingested and the free allowance

OneLens support: [e-mail]