The SS12000 specification don't have a pure teacher or student endpoint. So how can you receive a list of teachers?
However, the specification do define endpoints for persons working in a school. Each teacher should have an assigned duty, and there is an endpoint for duties.

Fetching duties
In this guide we'll use Postman to test our requests. You can download and use our Postman collection to easily get started working with educloud in postman. If you're new to postman you can learn how to import it in the "Importing our Postman Collection" guide.

Now, to fetch duties we simply make a request to https://api.ist.com/ss12000v2-api/source/SE00100/v2.0/duties.

This returns a list of every duty we have. We can see what school / organisation this duty belongs to, when it started and so on.
There is also the field dutyRole which defines what kind of work the duty represents.
In the API documentation you can see that there is a parameter we can use that lets us filter the results to only include those with the duty role of teacher (and since SS12000 is a swedish standard it's called "lärare"):

So what we need to do then is to add dutyRole as a query param, like so: https://api.ist.com/ss12000v2-api/source/SE00100/v2.0/duties?dutyRole=Lärare - Let's try it and see what kind of result we get back:

If you compare the two you'll see that the first visible object has changed from "Annan Personal" to "Lärare", meaning that our filter was successful.
What about the personal information about the teacher such as first name or their email addresses?
In order to get that we need to add one more parameter to our request.

Expanding the result with person

If we jump back to the documentation one last time we can see that the duties endpoint has another param that we can add to our request, which is the expand key. The expand lets us send in a string or a list of string to expand our request with additional data that the entity we're requesting might hold.

In the duty case shown below we have the option to expand on "person" which will include a data from the person entity as an embed.

All data that we get by using the expand key will be available via the _embedded key on the response.

And that's it! Now we've managed to get all the teachers from a specific customer from SS12000.
If you want to filter the data further, such as fetching teachers from a specific school you can use the "organisation" query param as well.

If you have any questions regarding this you're most welcome to ask them in the forums.

Schools holds a lot of data.
A municipality holds a lot of students (at the time of this writing Stockholm has 41796 registered gymnasium students, Gothenburg has 23399), and each student gets grades in 10 subjects (just to make it easier to count).
Fetching all the grades based on these two examples could potentially mean well over 100 000 grades. The size of one grade weighs about 1Kb, which would mean that the result would be 100 Mb.
That's a lot of data to download before being able to parse it. When the client make that request it needs to wait for the entire result to come back before it could handle the data, resulting in that the client times out before it can even get started.
You could see it as fetching water from a well. If you need 180 liters of water it's hard to take one big tank to the well by hand, fill it up and drag it back home.
Instead you use smaller buckets and run back and forth to the well until you've got everything you need. That's why it's better to use paginated results.

How do I paginate our SS12000 data?

Paginating our SS12000 data is very easy.
Use the query parameter limit in the request (https://api.ist.com/ss12000v2-api/source/SE00100/v2.0/grades?limit=1).
That will populate the the attribute pageToken in the response.

In this example I'm just using limit=1 but that is obviously just for this example.
In a real scenario a suitable page size would be between 1000 and 2000 items. It might be self-explanatory, but how many you should get in a single request all boils down to the size of the item (grades as mentioned above is 1kb per item, so 1000 grades would mean 1Mb per chunk).
Personally I would try and stick to around 1Mb.
 Anyway, the next time I do my request I just use that pageToken as a parameter to get the next page of data. When you have the pageToken you don't need the limit anymore.

When you reach the last page of the book (well, rather collection) the pageToken will be empty.
That way you know you're done.