CancellationToken should be implemented across the entire chain of methods. In this case, the entire chain of endpoints.
From a blog post from MS DevBlogs, describing Recommended patterns for CancellationToken:
Propagate your CancellationToken to all the methods you call that accept one, except after the “point of no cancellation” referred to in the previous point. In fact if your method mostly orchestrates calls to other methods that themselves take CancellationTokens, you may find that you don’t personally have to call CancellationToken.ThrowIfCancellationRequested() at all, since the async methods you’re calling will generally do it for you.
https://devblogs.microsoft.com/premier-developer/recommended-patterns-for-cancellationtoken/
Let's say that an user on the frontend begins an operation and then requests its cancellation.
ApiServer 1 endpoint's CancellationToken will change IsCancellationRequested property to `true`, which will propagate to inner calls that use this same CancellationToken; in this case, to Api Server 2. At the same time, the ApiServer 1 endpoint call will cease execution.
ApiServer 2 endpoint's CancellationToken will change IsCancellationRequested to `true`, which will propagate to inner calls; in this case, to the database. Due to the database principle of Atomicity (ACID principles)*, if the database transaction is ongoing**, then it will be completely cancelled and reverted. Also, at the same time, the ApiServer 2 endpoint call will cease execution.
* Considering the database follows ACID principles.
** If the database finished the transaction, but didn't finish communicating it to the caller, then the CancellationToken will have no effect.