CSRF tokens are usually only used for state-altering requests (POST, GET etc.), though one could use them for GET requests as well. The reason people don't do use CSRF for GET is that there's usually no risk involved when calling a GET endpoint from your browser, as it's not supposed to change the state of a resource in any way. And since an HTML form submission or included link will take the user directly to your API, there's no way for the attacker to extract the information afterwards (which is of course given if the attacker can make the request asynchronously via Javascript).

You can also use the "Referer" and "Origin" headers to defend your API against form submission from third-party websites without using any CSRF tokens (as browsers will include the URL/domain of the site from which the form was submitted), though there were numerous cases where browsers or e-mail clients didn't set these headers correctly, so if you really want to be sure the only way is to use a CSRF token. You can put that token e.g. in a JS-readable cookie, which will not be accessible on third-party websites but which you can read out via JS on your domain and then include in the POST/PUT/... request. If you want to run your code from different domains as well you will have to provide an endpoint from which users can get the CSRF token though (as Cookies from your API domain will not be readable there). You will then need to restrict that endpoint using CORS, as otherwise an attacker will be able to get a valid token and e.g. inject that into an HTML form which he/she can then submit.

So CORS and CSRF do different things, but for API-based apps that should be able to run on multiple (non-sibling) domains you need both mechanisms to ensure security (and CSRF needs CORS in that case to function).

CSRF tokens are a popular mitigation against CSRF, where CSRF is a "vulnerability" that arises in part when a user is tricked into asking its user-agent to make a request the user didn't actually intend.

This is particularly likely to happen in web browsers because they support hyperlinks or image tags to arbitrary destinations (which turn into GET requests), and support form auto-submission to arbitrary targets (which turn into POST requests). The request will often inherit the user's legitimate authentication posture on the target site, because all cookies and headers are also sent, riding on the user's existing session. Despite all this unpleasantness, a web browser adheres to the 'same-origin policy', which prevents the response from CSRF attack to be made known to the originating site. Given the predominance of interactive user-agents that support the same-origin policy, it's not very likely to be tricked into a CRSF with a user-agent that doesn't adhere to the same-origin policy.

CORS isn't a security feature per se, it's a mechanism to selectively relax the same-origin policy to obtain a response from a different source, if that source consents.