API Integration for Analysts
A four-part series for the people who specify integrations, rather than build them
There is a lot of good API material out there, and most of it is written for the people who will implement the thing. That is reasonable — they are the ones writing the code.
Analysts have an adjacent job. You help decide whether an integration is needed at all, what it must do, what happens when it fails, who has to be in the room, and what “done” means. Then you hand that to the people who build it. When your half is vague, theirs becomes guesswork, and the cost of that usually surfaces in month six rather than week one.
I put this series together for that half of the work.
What it covers
Part 1 — The integration landscape. How systems exchange data, what the common options are, how to choose between them, and the cases where the right answer is not an API.
Part 2 — Before build starts. Turning a business brief into requirements a developer can build from: functional and non-functional, error paths, data mapping, and the roles worth involving before design begins.
Part 3 — Secure API integrations. The security controls you meet in regulated environments, what each one protects against, and how to specify them sensibly without pretending to be a security architect. (In preparation.)
Part 4 — Documentation, testing, lifecycle. Documentation standards, the four families of testing, what tends to break in production, and using LLMs on analysis work without creating a compliance problem. (In preparation.)
How it is taught
Each part is a 90-minute session, delivered as a slide deck you can work through at your own pace, with a PDF fallback.
The examples are real systems from the Baltic region — vehicle registries, insurance bureaus, cross-border data exchange — because they are the ones this audience actually meets. The hands-on material runs against a live demo API built for the series: fully synthetic motor-insurance data, public credentials, and a deliberately flawed specification to pull apart.
Nothing here needs a corporate laptop, an account, or permission from anyone.
What it is not
This is a working map, not a deep dive. Each session goes far enough that you can hold your side of a design conversation and write a specification someone can build from — not far enough to make you an architect, and not a substitute for the reference material.
Where a topic deserves more than a session can give it, the pages point you at the sources I would go to myself.