You’ve already built a client database. You just might not think of it that way.
Every client you send reports for is in SendTidings. Every site, with its domain, its analytics source, its send schedule. Every report that’s gone out, with a date and a record. You added all of it so the monthly emails would reach the right people, but somewhere along the way it became a tidy, current list of who you look after and what you do for them. More current, often, than whatever’s in your actual CRM.
Until now that list only flowed one way: in. You could put clients into SendTidings; you couldn’t easily get them back out. As of today, you can. SendTidings has a read-only REST API (v1) so your clients, sites and report history can flow outward, into a CRM, a spreadsheet, an automation, wherever you need them.
What you get
Four endpoints, all read-only:
/api/v1/me: your organisation and account details./api/v1/clients: every client on your books./api/v1/sites: every site, matched to its client./api/v1/reports: the report history, what went out, and when.
Authentication is a bearer token. You create one in Organisation → Admin → API access, and — this is the important bit — it’s shown to you exactly once. Copy it somewhere safe, like a password manager or your automation tool’s secrets store, because we don’t keep it in a form we can show you again. If it leaks or you lose it, revoke it from the same screen and issue a new one. No drama.
If you can make an HTTP request, you can use the API directly. If you can’t — and most agency owners reasonably can’t be bothered — anything that speaks Zapier or Make can call it too. You don’t need to be a developer to wire this up; you need a tool that can hit a URL with a token attached.
A real example
Say you keep your client list in a CRM: Twenty, Attio, Folk, HubSpot, take your pick. Keeping it in step with reality is the usual chore: someone onboards a client in one place and forgets the other, and three months later the two lists quietly disagree.
Point a nightly job at /api/v1/clients, drop the results into your CRM, and the chore goes away. Every morning your CRM reflects whoever’s actually in SendTidings, because SendTidings is where a client lands the moment you start reporting for them. One source of truth, syncing itself while you sleep. Set it up once in Zapier, or as a ten-line script on a cron, and never think about it again.
What it isn’t, yet
Worth being straight about: this is read-only. You can pull your data out of SendTidings; you can’t push changes back in through the API. Create a client in your CRM and it won’t appear in SendTidings on its own, not today. So it isn’t a full two-way sync, and I’d rather tell you that now than have you find out halfway through building something.
Read-only is the sensible place to start, though. It’s the half everyone needs first — get the client list flowing outward, make SendTidings the source of truth it already quietly is — and it’s the foundation the rest sits on.
The groundwork
Because that’s what this really is: groundwork. A clean, documented way to read your data is the thing every deeper integration needs underneath it. Direct CRM connectors, two-way sync, the bits that save you the Zapier step entirely: they all build on top of an API like this one. We’ve started with the part that’s useful on its own and opens the door to the rest.
Your client list has been sitting in SendTidings this whole time, quietly staying accurate. Now it can go to work everywhere else, too.
Tokens live in Organisation → Admin → API access.
