CSRF relies on the browser sending the cookie with a cross-site request automatically, since Javascript/attacker's site don't have access to the cookie.

CSRF protection relies on the server correlating something the browser sends automatically (the cookie) with something in the form (the token).

A non-browser client will be in control of both the token and the cookie so can make them match (if it can get the cookie at all).

TL/DR - CSRF is inherently a browser attack, so protections against it are only required when talking to a browser.

It comes down to the fact that CSRF is an attack against browsers, so if your service is exclusively used by non-browsers there's no point in using anti-CSRF defences, which can be expensive so may be worth disabling.

When a browser interacts with a server, each request comes in separately, so if the service wants to have authentication it needs to add in some scheme to connect requests (to avoid having to have the user authenticate every request). One common way is to set a cookie to the user's browser, which is automatically send when every subsequent request by the browser).

1. Client logs into service
2. Server sets a http-only cookie
3. Malicious script in browser sends a request to e.g. transfer money to the attacker (browser automatically attaches cookie)
4. User loses money

vs. with protection

1. Client logs into service
2. Server sets a http-only cookie
3. Malicious script in browser sends a request to e.g. transfer money to the attacker (browser automatically attaches cookie)
4. Server rejects the request as the it doesn't have the correct CSRF fields.

However malicious scripts can make requests to the server, and the browser will helpfully included the cookie. However the script won't have access to the cookie directly (assuming the right cookie option is specified). Therefore a protection against CSRF is to have something in the request separate from the cookie (i.e. a hidden field on a form) that can be verify the request came from a proper form, rather than a script.

CSRF relies on the browser sending the cookie with a cross-site request automatically, since Javascript/attacker's site don't have access to the cookie.

CSRF protection relies on the server correlating something the browser sends automatically (the cookie) with something in the form (the token).

A non-browser client will be in control of both the token and the cookie so can make them match (if it can get the cookie at all). So there's no point having complicated CSRF protection if the service is never going to be accessed by a browser.

TL/DR - CSRF is inherently a browser attack, so protections against it are only required for services that might be accessed by a browser.