Glassdoor API: Asking for 10 Reviews Bills You for 50

Copy this line to your agent to pull a company's employee reviews.

set up https://monid.ai/SKILL.md and use akta /v1/company/employee-reviews with limit 50

We called an employee-reviews endpoint twice on 2026-10-03, changing nothing but the limit. Asking for 10 reviews returned 10 and billed 50 units. Asking for 100 returned 100 and billed 100. The small request cost five times as much per review as the same money would have bought at 50. Then we read the ratings, and eight of them share one array while using two different scales. This guide runs through Monid, the OpenRouter for agent tools.

What does a Glassdoor API return?

Three layers, and only one of them is the reviews.

The headline rating

One number for the company. Ours came back as overall_rating.glassdoor: 3.6. It is namespaced by provider, which tells you the shape is built to carry more than one source even when only one answered.

The dimension ratings

Eight more numbers covering compensation, culture, diversity, senior management, work-life balance, business outlook, CEO approval and whether people would recommend the place. This is the layer most people actually want, because a single 3.6 hides whether the problem is pay or management.

On our company, senior_management was 2.9 against a 3.6 overall, the lowest of the eight. That gap is the whole value of pulling the dimensions.

The reviews

A list of individual reviews, 21 fields each. pros and cons arrive as separate fields rather than one body, which saves you a parsing step, and every review carries its own seven sub-ratings, a job title, whether the person still works there, how long they stayed, and how many readers found it helpful.

The count you should read first

reviews.total reported 259 for this company, with a total_by_provider breakdown beside it. That number tells you whether paging is worth starting before you pay for the first page.

📖 See also Software Review Data by API: G2 and Capterra

Why did asking for 10 reviews bill 50?

Because the billing unit has a floor and limit does not respect it.

Two calls, same company, same day:

The price type is PER_UNIT at a rate per 50 units, so 50 is the minimum purchase. Pass anything below it and you buy 50 units and receive what you asked for.

What that does to the per-review cost

limit 10   50 units  ->  10 reviews   = 5 units per review
limit 50   50 units  ->  50 reviews   = 1 unit per review
limit 100 100 units  -> 100 reviews   = 1 unit per review

A limit of 10 is the single worst value available on this endpoint. It costs the same as 50 and delivers a fifth of the data. There is no case for passing a limit between 1 and 49: round up to 50 and keep the rows.

Why this is easy to get wrong

Because limit usually means "spend less". Here it means "receive less", and the spending floor sits somewhere you cannot see from the parameter list. The endpoint's own docs give the default as 10, which is exactly the value that wastes the most.

The habit this suggests

Read price.type before you tune a limit. A PER_CALL endpoint does not care what you ask for. A PER_RESULT endpoint rewards a small limit. A PER_UNIT endpoint with a block size punishes any request smaller than the block, and the block size is in the receipt rather than in the parameter description. The same reasoning applied to a different billing model is in the per-contact pricing guide.

Why are eight ratings on two different scales?

Because three of them are proportions and five are scores, and nothing in the array says which is which.

business_outlook            0.54
ceo                         0.88
recommend_to_friend         0.55
compensation_and_benefits   3.8
culture_and_values          3.7
diversity_and_inclusion     3.9
senior_management           2.9
work_life_balance           3

The first three are shares between 0 and 1: 88% of reviewers approve of the CEO, 55% would recommend the company, 54% expect business to improve. The last five are the familiar five-point averages.

The mistake this invites

Every entry has the same shape, { type, provider, value }, and sits in the same array. Normalise the array to a five-point scale and ceo: 0.88 becomes a damning 0.88 out of 5 instead of a healthy 88% approval. Divide everything by five instead and compensation 3.8 becomes 76% when it is really 3.8 out of 5.

Keep a per-type map of which scale each key uses and apply it on ingestion. Three keys are proportions, five are scores, and that is a constant you can hardcode.

A sanity check that catches it

Any value under 1.0 in this array is a proportion, and any value above 1.0 is a score. That heuristic works on the data we saw, and it fails the day a company genuinely scores 0.9 out of 5 on something, which is why the explicit map is the real answer and this is only the alarm.

What the dimensions are worth

The gap, not the level. A 3.6 overall tells you nothing actionable. A 3.6 overall with senior_management at 2.9 and diversity_and_inclusion at 3.9 tells you where the complaints are, and for a sales use case it tells you which pitch will land.

How do you pull a company's employee reviews?

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main

The call, with the limit that does not waste money

monid run -p akta -e /v1/company/employee-reviews \
  --query '{"company":"https://figma.com","limit":50}'

company takes a website or a company name. limit maxes at 100 and should never be set below 50. offset pages.

Read the total before you page

const { total } = res.data.employee_reviews.reviews;   // 259 for ours
const pages = Math.ceil(Math.min(total, cap) / 100);

259 reviews is three calls at limit 100. Decide whether you want all of them before the first one, because the floor means there is no cheap exploratory call.

Split the ratings on ingestion

const PROPORTION = new Set(["business_outlook", "ceo", "recommend_to_friend"]);
const ratings = {};
for (const r of res.data.employee_reviews.other_ratings) {
  ratings[r.type] = PROPORTION.has(r.type)
    ? { pct: r.value * 100 }
    : { score: r.value, outOf: 5 };
}

Keep the sub-ratings on each review

Every review carries its own seven dimension scores alongside the aggregate. That is what lets you ask whether the management complaints come from current or departed staff, which the company-level average cannot answer and which is the most useful question in the payload.

📖 See also Company Name to an Employer Review Feed

Which endpoint should I use for which job?

Every row was verified with monid inspect on 2026-10-03. Billing shape is given rather than figures, because shape drives design and current numbers live on monid.ai/tools.

The four rows describe four different populations and people mix them up constantly. Row one is what staff say about working somewhere. Rows two and four are what customers say about buying. Row three is what clients say about an agency. A reputation report that blends employee and customer sentiment into one score is measuring nothing, and the only one of these that tells you about an employer is the first.

When should you not use this?

Four cases.

You want one number for a lot of companies. The floor makes a shallow sweep expensive: 50 units per company whether you read 10 reviews or 50. For a hundred companies that is a real invoice, and if all you need is the headline rating, look for an endpoint that sells the aggregate on its own.

You are screening individuals. This is company-level data. It says nothing about a person, and the reviews are written by people who did not expect to be identified from a job title and a date.

You need every review ever written. The total reported here was 259 and that is what this provider's index holds. A company's own Glassdoor page may show a different count, and neither is the complete history.

You are making an employment decision about a named person. Reviews are anonymous, unverified and self-selected: people write them when they are delighted or furious. They are a useful signal about a company and a terrible basis for anything about an individual.

And the disclosure: we resell this endpoint. The most valuable line in this post is that you should never pass a limit below 50, which saves money on a call you make through anyone.

Conclusion

One endpoint, two calls, one parameter different. limit: 10 returned ten reviews and billed fifty units. limit: 100 returned a hundred and billed a hundred. The billing unit comes in blocks of fifty, so anything below that floor buys the full block and delivers a fraction of it, and the default value of ten is the worst number you can pass. Round up to 50.

Then read price.type before tuning any limit anywhere. A per-call endpoint ignores it, a per-result endpoint rewards a small one, and a per-unit endpoint with a block size punishes you for asking small. That distinction lives in the receipt, not in the parameter description.

The ratings carry the second trap. Eight dimensions share one array and two scales: CEO approval, business outlook and recommend-to-friend are proportions between 0 and 1, while the five familiar categories are out of five. Our CEO value was 0.88, which is 88% approval and reads like a catastrophic score if you normalise the array blindly. Hardcode the three proportion keys and apply the split on ingestion.

Free next step: run monid inspect -p akta -e /v1/company/employee-reviews, note the PER_UNIT price with its block size, then make one call at limit 50 and one at 10 and compare billedUnits. The floor is visible in two calls. Start at monid.ai.

FAQ

Last updated October 2026.