Getting data out of Cornerstone: REST, Reporting API, or Data Exporter?

Ask five Cornerstone OnDemand (CSOD) administrators how to get data out of the platform and you will get five different answers, most of them right, all of them partial. Cornerstone has more ways out than almost any HR system we work with, and that is exactly the problem: the hard part is not finding an API, it is picking the right one before you have built the wrong thing.

We have built on most of them, for most reasons. Here is the whole map in one place, and a simple way to choose.

The four-and-a-bit ways out

There are, in practical terms, four routes your data can take out of Cornerstone, plus one you can only use from inside the platform's own web pages.

• REST API – real-time, read and write, one record at a time. Rich nested objects for a single user, transcript, or learning object. This is the route when you need to do something (assign training, update a user) or show one person's data the instant it changes.
• Reporting API (RAPI) – programmatic, read-only, OData, fed by Cornerstone's Real-Time Data Warehouse. Broad reporting views. Still around, still useful, but no longer where Cornerstone is investing.
• Data Exporter API (DEAPI) – the modern bulk workhorse. Read-only, OData, delta sync, built for pulling thousands of records efficiently. Cornerstone calls it "the spiritual successor to RAPI" and says it will "over time, start to deprecate RAPI endpoints if the same data can be retrieved via DEAPI."
• Bulk API – for loading data in (and a few heavy export jobs), with its own tight per-endpoint throttles and data limits. Different tool, different job.
• The reporting screens – Reporting 2.0 and the older Standard Reports, the in-platform tools a person operates to build, run, schedule, and export a report to CSV or Excel. Great for a human running a report; not an integration surface. We covered their limits in the Reporting 2.0 write-up.

A decision in three questions

You almost never need to weigh all of them. Three questions settle it.

Are you writing, or just reading? If you need to create or update anything, that is the REST API, full stop. The DEAPI and RAPI are read-only.

One record now, or many records over time? If you need one person's data reflecting a change this second – someone just completed a course and expects to see it – that is REST, because the reporting APIs run through a data warehouse with a lag. If you need broad, historical, or bulk data to feed a dashboard, a warehouse, or a BI tool, that is the DEAPI.

Are you on RAPI today? Then plan your move to the DEAPI. It works for now, but you are building on the API Cornerstone is walking away from. New work should start on the Data Exporter.

That is the whole framework. Writing → REST. One live record → REST. Broad/bulk/historical → DEAPI. On RAPI → migrate to DEAPI.

The lag nobody puts on the slide

Both reporting APIs – RAPI and the DEAPI – read from the Real-Time Data Warehouse, and "real-time" there comes with an asterisk: expect a lag of around fifteen minutes in production between something happening in the portal and it appearing in a query. For dashboards, trends, and anything aggregate, that lag is invisible. For "show me this one person right now," it is a support ticket waiting to happen. The mistake is not the lag; the mistake is using a warehouse-fed API for a real-time question. We go deeper on that, and on the throttle limits that catch everyone, in the Data Exporter API guide.

Rate limits apply to all of it

Whichever route you take, Cornerstone meters it. The Foundational APIs share a budget of 417 requests per minute, 25,000 per hour, and 600,000 per day, counted per environment and per endpoint – not per user or per token, so you cannot buy headroom by adding credentials. The DEAPI runs on a far tighter per-minute budget. The Bulk API's job endpoints are throttled harder still. Build any of this without a back-off strategy and you will meet a 429 at the worst possible moment.

The honest bit

Here is what all of this adds up to: choosing the right Cornerstone API is a genuine architecture decision, and living with it – the rate limits, the warehouse lag, the deprecation path, the retries, the schema translation – is ongoing engineering. Most teams do not want to own an integration layer. They want their data.

The direction of travel makes that matter more, not less. Cornerstone now brands the platform Cornerstone Workforce AI and sells it as interoperable, built to connect "cleanly … to any system of record or datastore." Clean, reliable data-out is the half of that promise you actually have to build.

What you build on these APIs is a spectrum. At the light end, role-aware MicroApps that surface live Cornerstone data right inside the portal – the middle ground between the native platform and a full warehouse. At the other end, a platform that syncs everything out and keeps it current.

That is what octo.taxi is. We made the choices above once, properly, and run the sync so you do not have to. Your Cornerstone data lands in a place with dashboards, an org chart, plain-language answers, downloadable reports, a live BI feed, and a clean REST API of your own – a two-way door that swings out to wherever you need the data next.

Pick the right tool if you are building it yourself; we hope this map saved you a wrong turn. Or skip the map, and let your data just get where it is going.

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

---

Sources. Cornerstone's developer documentation: API throttling limits & headers · Reporting API considerations (DEAPI as the successor to RAPI) · Bulk API throttling limits · Bulk API data limits.