REST APIs for Analysts: The Part You Actually Need to Know
You don't build REST APIs as an analyst, but you call them all day. Here's the practical REST literacy that pays off in GA4, connectors and dashboards.
7 min readBranislav Mateas
Copy post as Markdown
On this page
Why an analyst should care about REST at all
Let me be honest up front. As a digital analyst, you will almost never build a REST API. That's a developer's job, and that's fine.
But you call them constantly, whether you notice it or not.
Every time you pull data from the GA4 Data API, push an event through the Measurement Protocol, or wire a Google Ads connector into Looker Studio, there is a REST API doing the work underneath. When something breaks, the error you see is a REST error. When you hit a wall pulling reports, it's usually a REST limit.
So the goal here is not backend depth. It's practical literacy. Enough to read the docs, call an endpoint, and understand why it did what it did. That's it.
REST stands for Representational State Transfer. It's an architecture for web APIs, first described in Roy Fielding's 2000 dissertation. Fielding also co-authored HTTP, which is why REST and the plain web share so much DNA. An API that follows REST conventions is called RESTful. That's the vocabulary out of the way.
Here's the idea that took me the longest to internalise, and the one that matters most.
REST is data-oriented, not procedure-oriented.
Older web services (RPC, SOAP, if you ever meet them) are built around remote procedures you call, like functions living on another machine. REST throws that out. Instead, everything is a resource with its own address, and you act on it with a small set of standard verbs.
You can safely ignore SOAP and XML-RPC in day-to-day analytics work. They exist, they're mostly legacy, and you'll rarely touch them. Good to know the names, nothing more.
So a resource is a thing: a user, an article, a report. Its address is a URI, like /api/users/pepa. And the action you want lives in the HTTP method, not the URL.
Resources, verbs, and the CRUD you already understand
The four basic operations go by the name CRUD, and they map neatly onto HTTP verbs. If you've ever filled out a form on the web, you already know these intuitively.
Notice the naming pattern too. Resource names are nouns, usually plural (/articles, /comments), and the verb is the HTTP method, never the URL. Nested relations read like plain English: GET /articles/1/comments/5 means comment 5 on article 1.
And query parameters, the bits after the ?, filter and shape your results. GET /articles?count=100 is the same pattern you use in normal URLs every single day.
GET: read data. GET /articles returns a list, GET /articles/1 returns one article. This is the everyday request you'll use most.
POST: create something new. You post to a shared endpoint and the server assigns the ID.
PUT: replace the whole resource, like a SET.
PATCH: partial update. Send only the fields that changed, so less data goes over the wire.
DELETE: remove the resource, e.g. DELETE /articles/1.
Status codes: how to read what an API is telling you
This is the part I'd actually memorise, because it saves you the most time.
Every response comes with an HTTP status code. The first digit tells you the class: 1xx is informational, 2xx is success, 3xx is a redirect, 4xx is your mistake (client error), and 5xx is the server's mistake.
The rule of thumb: 4xx means look at your own request first.
Here are the ones worth recognising on sight.
200 OK: it worked.
201 Created: your POST created a new resource.
204 No Content: it worked, there's just nothing to return.
400 Bad Request: your request is malformed, often broken JSON.
401 Unauthorized: you're not authenticated.
403 Forbidden: you're authenticated but not allowed.
404 Not Found: the resource doesn't exist.
422 Unprocessable Entity: a validation error, the data didn't pass checks.
429 Too Many Requests: you hit a rate limit.
The one status code that will bite you: 429
If you take one thing from the list above, take 429.
Too Many Requests means you called the API faster or more often than it allows. It's extremely common when pulling from analytics and ad-platform APIs, especially if you're looping through markets, date ranges, or accounts.
So design for it. Spread requests out, batch where you can, and don't build a pipeline that fires hundreds of calls in a burst and then falls over at 9am on Monday. Ask me how I know.
A few properties that explain the weird bits
Some REST behaviour looks strange until you know the why behind it.
REST is stateless. Every request carries its own authentication, and the server keeps no memory between calls. That's why API calls send a token each time instead of leaning on a session cookie. It's also why REST scales and runs in parallel so well.
JSON is the de-facto format. REST can technically return XML or other formats, negotiated through the Content-Type header, but modern APIs speak JSON. That's why you see JSON everywhere as an analyst.
Caching, compression and pagination are all built on plain HTTP. ETag and Last-Modified handle caching, GZIP shrinks payloads, and Link headers plus X-Total-Count let you page through large result sets. When a report comes back in chunks, that's pagination doing its job.
On authentication, the standard you'll meet is OAuth. It's what Google APIs use. There's a simpler option called HTTP basic auth, but it sends credentials in the clear, so avoid it.
Where you'll actually meet REST as an analyst
This is where the literacy pays off. These are the tools I reach for, and every one of them is REST underneath.
My honest advice: before you wire an endpoint into a pipeline, poke it first. Use cURL on the command line or Postman if you prefer a GUI, and just read the raw JSON that comes back. Seeing the actual shape of the data before you automate anything will save you hours.
GA4 Data API: pulling report data programmatically instead of clicking around the UI.
GA4 Admin API: managing configuration in code rather than by hand.
Measurement Protocol: sending events to GA4 server-side via an HTTP POST.
Ad-platform and CRM connectors (Google Ads, Meta, HubSpot) and BI tools like Looker Studio and Power BI, all quietly making REST calls when they refresh.
A nice-to-know so the docs stop confusing you
You'll sometimes see people argue about whether an API is really RESTful. That comes from the Richardson Maturity Model, which splits REST into levels.
Level 0 is plain HTTP as a transport. Level 1 adds resources with multiple endpoints. Level 2 uses HTTP verbs and status codes properly, and this is where almost every real-world REST API lives. Level 3 is HATEOAS, where responses include links to related resources so the client navigates by following them.
Level 3 is rare in practice. So if you assume Level 2, you'll be right most of the time. Don't lose sleep over the purity debates.
The takeaway
You don't need to become a backend engineer to work confidently with APIs. You need a handful of ideas, and the rest is reading docs.
Here's what I'd keep in your head:
Think resources and verbs, not procedures. Nouns in the URL, action in the HTTP method.
Read status codes first. 4xx is usually you, 5xx is the server, and 429 means slow down.
Expect JSON, expect OAuth, expect pagination on big pulls.
Test an endpoint with cURL or Postman before you automate it.
Thanks for reading
Understanding how data actually moves between systems is a quiet superpower for an analyst. Programming without context is just code. Knowing how the information flows, and being able to read what the API tells you, is what turns a broken pipeline into a five-minute fix.
If you're doing GA4 or GTM work and something in your data feels off, or you just want to talk REST, connectors and dashboards, reach out. Links are in the footer at bmateas.com/contact.
I'll come back to more of the analyst-meets-code stuff soon.
