The Cornerstone Data Exporter API (DEAPI), and the throttle limits nobody warns you about

The first time we pulled a full learning transcript out of Cornerstone through the Data Exporter API, it worked beautifully. So we ran it again. And again. Somewhere around the fourth loop, Cornerstone stopped being polite and started returning 429 Too Many Requests. No warning, no grace period. Just a wall.

If you have ever built anything against the Cornerstone Data Exporter API, you know the wall. This is the guide we wish someone had handed us before we hit it, written for the HRIS analysts, integration engineers, and people-analytics folks who need their Cornerstone data out and moving, and would rather not learn the rate limits the hard way.

We will save you a few hair-raising late nights.

What the DEAPI actually is (and what it isn't)

Cornerstone gives you three main ways to get data out, and people mix them up constantly.

• The REST API is real-time and gives you rich, nested objects for a single user or record. Great for "show me this one person, right now."
• The Data Exporter API, or DEAPI, is the bulk workhorse. It speaks OData, so you filter with $filter, pick columns with $select, and page with $top. It is built for broad queries across thousands of records, and it supports delta sync so you pull only what changed.
• The Reporting API (RAPI) sits on top of the older reporting views. It still has its uses, but it is not where new integrations should start. Cornerstone itself calls the Data Exporter the spiritual successor to RAPI and says that "over time, we will start to deprecate RAPI endpoints if the same data can be retrieved via DEAPI." The platform is walking toward the DEAPI. Walk with it.

Two things about the DEAPI trip everyone up.

First, it is read-only. You cannot write back through it. If you need to create or update a transcript, that is a REST job.

Second, the DEAPI uses the numeric user_id, while the REST API uses employeeRef, the external ID string. They are not interchangeable. We have watched smart people lose an entire morning because they filtered a DEAPI call with a REST-style ID and got a clean, confident, completely empty response.

REST vs Reporting API vs DEAPI: which one, when

Because these three get muddled constantly, here is the whole decision in one table.

The short version:

• Need to write something, or need one person's data this second? That is REST.
• Need broad, bulk, or historical data across many people – the stuff dashboards, exports, and warehouses are made of? That is the DEAPI.
• Still on RAPI? It works today, but plan your move to the DEAPI, because Cornerstone is walking the same way.

The throttle limits, in actual numbers

Here is the part the documentation makes you dig for. These are the ceilings you are working against.

The Foundational (REST) APIs share a generic budget of 417 requests per minute, 25,000 per hour, and 600,000 per day – Cornerstone states this directly in its throttling guide.

Two things about how that budget is counted, because they catch people out. First, the limits are per environment: Cornerstone says plainly that "throttle limits are for each environment," so your Pilot, Stage, and Production portals each get their own. Second, they are tracked at the endpoint level – the throttling headers are urilevel headers, and the per-minute figure is just the hourly limit divided by sixty. So this is not a per-user or per-token quota you can escape by adding more credentials. Everything hitting a given endpoint in a given portal draws from the same bucket, which means your real headroom depends on what else is talking to that portal – other integrations, other admins, a scheduled report firing at the wrong moment – not only on your own code.

The Data Exporter API runs on a far tighter per-minute budget – on the order of 120 calls per minute per portal, documented in Cornerstone's Data Exporter API guide. That is the number that catches people. It sounds like plenty until you are paging through a large transcript object and firing a call every fraction of a second. You reach it faster than you would guess.

Cornerstone does tell you where you stand, in two response headers it documents alongside the limits: x-csod-throttling-rate-limit-urilevel (your hourly ceiling) and x-csod-requests-remaining-urilevel (what you have left). Watch the remaining count, and slow down before Cornerstone slows you down for you. A 429 is not a disaster, but backing off on your own terms beats getting bounced mid-job.

And sometimes the wall has nothing to do with your rate budget at all – Cornerstone itself is having a bad morning. When calls start failing in a way that does not look like throttling, rule out the simplest cause first. We keep a free live status page for every Cornerstone environment worldwide, refreshed every minute, for exactly that "is it me or is it them?" moment.

The 15-minute lag that will embarrass you in a meeting

The DEAPI is fed by Cornerstone's real-time data warehouse, and "real-time" here comes with an asterisk. In production, expect around a 15-minute lag between something happening in the portal and it showing up in a DEAPI query. On demo and staging portals it can lag hours, sometimes more.

For most of what the DEAPI is built for, this barely matters. Headcount trends, completion rates, department breakdowns, any aggregate view across thousands of people – a fifteen-minute lag is invisible there, because the big picture does not move minute to minute, and a nightly sync cares even less. Where the lag bites is the individual, real-time moment: someone completes a course, refreshes the screen expecting to see it, and it isn't there yet. That is a job for the REST API, not the DEAPI. Reach for the wrong one and you will spend ten minutes explaining data warehouses to a room that did not ask. So know which question you are answering – the overview or the single action – and build the lag into whatever you promise people.

The gotchas that cost real time

A few more things we learned by getting them wrong.

There is no lo_core, and you don't need one. People go looking for a learning-object "core" object that doesn't exist, then fall back to calling the /LO/GetDetails REST endpoint once per learning object just to get titles. That per-LO fan-out is the single most common way we see people burn their rate budget for nothing. The learning-object data you actually want – titles, descriptions, type, duration – is already sitting in the Data Exporter's own exports, available in bulk. You almost never need those per-LO REST calls.

Status fields are numeric codes, not labels. A transcript status comes back as "64", not "Completed". A user status of "1" means Active. The codes are consistent, but you have to map them yourself, and the numbering pattern is not always intuitive, so treat every status field as an opaque string and translate it explicitly.

What it actually takes to live within the limits

None of this makes the DEAPI bad. It is fast, it is well-structured, and the underlying design is genuinely good. It just means that getting your data out reliably is a real, ongoing engineering job, not a script you write once and forget.

Doing it properly means, at a minimum:

• Syncing only what changed, instead of re-pulling the whole portal every run.
• Shaping every request to the limits – the right batch sizes, the right paging, and knowing where the ceilings sit before production finds them for you.
• Backing off gracefully as you approach the limit, and recovering cleanly from the 429s you will occasionally get anyway.
• Translating Cornerstone's raw shape – the numeric codes, the ID mismatches, the localized fields – into something your dashboards and your BI tool can actually read.
• Keeping the stable data cached, so you are not asking Cornerstone the same question every single run.
• Watching all of it, because when a sync quietly falls behind, you want to find out before the board does.

Each of those is its own small rabbit hole. Together they are a system somebody has to own – and keep owning, through every Cornerstone release, every schema change, and every new module you switch on.

The honest bit

Here is the thing, though. Everything we just walked through is work. Real, ongoing, someone-owns-this work. Rate-limit handling, permission juggling, status-code mapping, the 15-minute lag, the retry logic, the paging. It is the kind of work that is invisible when it runs and very visible when it breaks, usually the week you are on holiday.

We got tired of writing it over and over for every client, so we built octo.taxi to do it once and do it properly. It syncs your Cornerstone data through the DEAPI, handles the throttling and the delta logic and the retries, and hands you clean, current data with dashboards, an org chart, plain-language queries, and a REST API of your own. No 429s. No scope arithmetic. No explaining data warehouses to the board.

You should not have to become a rate-limit expert to see your own numbers. But if you are going to build against the DEAPI directly, we hope this saved you the wall we walked into.

Either way, your data should move freely, from A to B, in style.

---

Sources. Cornerstone's own developer documentation, for anyone who wants to check the numbers: API throttling limits & headers · Data Exporter API guide · Reporting API considerations (DEAPI as the successor to RAPI).