Semrush API: the bill is set per row of data returned, not per request, so a loose query is the expensive mistake

The Semrush API is priced in API units, and the number of units a request consumes depends on the report you called and on how many rows it returned. Semrush's own developer documentation gives the shape of it plainly: one line of a domain organic keywords report costs ten units for live data and fifty units for historical data, and historical data from the analytics reports costs more than live data generally. That single fact decides almost everything about what an integration costs, because it means your bill scales with the width of your query rather than with how often you call it. A script that asks for every keyword a domain ranks for, every week, for forty competitors, is a large bill built from a small amount of code.

The three things that set the cost of any call

What varies	How it moves the cost	What to do about it
The report you call	Each report type has its own unit cost per line, and they differ by a wide margin	Read the per report rate in the developer documentation before choosing an endpoint, not after
Live or historical data	Historical costs a multiple of live for the same report. The documented example is ten units a line live against fifty historical	Pull history once into your own store, then keep it current with live calls
How many rows come back	Cost is per line returned, so an unbounded query is an unbounded bill	Set an explicit row limit on every call, and filter server side rather than in your own code

The third row is where real money goes. Filtering after the fact feels harmless and is not: if you request five thousand rows and keep two hundred, you paid for five thousand. Every unit of waste there is permanent.

The arithmetic, in four lines

Do this before you ask for a quote, with your own numbers rather than an example.

• Rows per call. How many lines do you actually use from one call, after your own filtering. That is the number to request.
• Units per row. Take it from the documentation for the specific report, and check whether you are asking for live or historical.
• Calls per cycle. Domains multiplied by reports multiplied by how often you refresh. Weekly against daily is a factor of seven on the whole bill, and for most reporting a weekly reading is the one people actually look at.
• Multiply. Rows times units per row times calls per cycle times cycles per month. That is your monthly unit consumption, and it is the only number worth taking into a conversation about packages.

The shape of that calculation is the same one that decides the cost of a rank tracking subscription, where the limit is keywords multiplied by how often you check them, as set out in the plan limit is keywords multiplied by how often you check them. In both cases the frequency is the term people set carelessly and the one that multiplies everything else.

Access and units are two separate purchases

This catches teams at the worst moment, which is after the subscription is approved. Having API access on your plan and having units on your account are different things, and the documentation is explicit that units have to be on the account before a key returns data. So a key that authenticates correctly and returns nothing useful is usually an account with no units rather than broken code.

Which subscription tier carries API access, and what a package of units costs, are the two figures that move and the two that third party summaries disagree about most. Published articles name different plans and different prices, and Semrush does not publish unit package prices on its public pages. Take both from Semrush's own API access page and from Semrush directly, and get the answer in writing before the build is scheduled. Where the subscription tiers sit generally, read off the vendor's own pricing page with a date on it, is in Semrush pricing, the plans as published.

The four questions to settle before anybody writes code

• Which exact reports does the use case need? Name the endpoints, not the subject area. Two reports that sound similar can differ several fold in units per line, and the cheaper one often answers the question.
• Live, historical, or history once then live? The third option is almost always right and is the single biggest saving available.
• What is the refresh interval the business will actually read? Build for the cadence of the meeting, not for the cadence a dashboard could support.
• Where does the data land, and who owns that store? An integration that re-queries for every page view of a dashboard is paying repeatedly for the same rows. Pull once, store it, and serve the dashboard from your own store.

When the API is the wrong answer

The interface and its exports cover a surprising amount of what people reach for an API to do, and they consume no units.

• A one off analysis. If the question is answered once, export from the interface and work in a spreadsheet. The integration costs more than the answer is worth.
• A client report on a monthly rhythm. The scheduled reporting and the report builder inside the product exist for this, and the output is a document a client reads rather than rows a developer has to assemble.
• A handful of domains watched continuously. Projects and position tracking inside the interface already do this, with alerting, and the API adds cost without adding the answer.

The API earns its place when the data has to sit beside data from somewhere else, when the volume is beyond what a person can export and reconcile, or when something automated has to act on a change rather than a person reading about it.

Semrush API questions a build has to answer

What is an API unit?

It is the accounting unit Semrush bills API usage in. The documentation prices requests in units, with a rate per line of data that depends on the report and on whether the data is live or historical. The documented example is ten units per line for a live domain organic keywords report and fifty per line for the historical version.

Which plan includes API access?

Take this from Semrush's own API access page rather than from any summary. Third party articles name different tiers, partly because the plan line up has changed and some documentation still references a tier Semrush now labels legacy. The reliable approach is to confirm the current tier and the unit package in writing at the point of purchase.

Do I get units included with my subscription?

Treat units as a separate line to confirm rather than an assumption. The documentation describes units as something that has to be on the account before requests return data, and the allowance attached to a given tier is one of the details that has moved. Ask what the monthly allowance is and what an additional package costs, together, in one question.

How do I keep the cost down?

Four moves, in order of effect: cap the rows on every call, pull history once and refresh with live data, set the refresh interval to the cadence somebody actually reads, and store the results so a dashboard never triggers a new call. Those four usually matter more than the package you buy.

Is there a free tier to test against?

Plan the test as part of the purchase conversation rather than hoping for one. A sensible test is one endpoint, a capped row count and a single domain, which tells you whether the fields are the fields you need before any volume is committed.

Can I get this data through an assistant instead?

Semrush's own feature list names a connection that brings its data into AI assistants alongside the API. That changes the interface rather than the accounting, so ask the same questions about what it consumes and which subscription carries it before building a workflow on top of it.

The reading no API exposes yet

An API gives you rows about a results page. A growing share of buyers never reach one: they ask ChatGPT, Gemini, Perplexity or Claude who to use in a category and get back three or four companies with a sentence of reasoning each. There is no position, no volume and no endpoint for that, because the answer is composed rather than ranked, and it is assembled from what has been published about each company. The reading that does exist is which names come back and which sources the answers leaned on. AI Knows Us asks those buying questions across the main assistants and records who gets named and what the answers were built from.