To avoid xss attack, MVC generating some antiforgery token.
But in our project we have Angularjs with web api.
My need is
The antiforgery token is against cross-site request forgery (CSRF). In very short and somewhat simplified, an attacker may be able to set up his own website, trick your user into visiting that website, and then create a webpage for the user that will make the user's browser post a valid request to your application, something your user did not want to do. The standard protection against this is generating a random token in your application that the attacker won't know and won't be able to send. OWASP has a nice description of CSRF and also a protection cheat sheet. This problem only comes up if authentication info (the session id or access token) is sent automatically by the browser with requests, ie. when it is in a cookie. Otherwise the attack is not possible.
This has nothing to do with cross-site scripting (xss). An attacker may want to inject Javascript into your page when viewed by other users so that he can access data displayed to or stored on the client by victim users. To solve this, you need to encode all output according to its context, or in Angular (and Javascript in general) you need to make sure that you only use bindings that may not create a script node in the page dom but only bind as text. OWASP has a cheat sheet for XSS too.
In case of Angular talking to Web API, you need to take care of CSRF in the Web API code if (and only if) you use cookie-based authentication / sessions. If the access token is stored anywhere else and you have to insert it into each request in code (like for example the token is stored in a Javascript object and added to each request as a request header by jQuery), it's fine and you don't need further protection against CSRF.
If the Web API serves JSON content, it's fine to have unencoded data in JSON responses (obviously this means you should encode data for JSON itself, but standard serializers do that for you, and you don't need to care about presentation at that level). When such data is received in Angular, you need to make sure that you only use safe bindings to actually bind that data to the UI so that Javascript cannot be inserted. Angular is reasonably good at that, but code can still be vulnerable. Also DOM XSS (a form of XSS) is a very common vulnerability in Javascript-heavy applications.
How exactly to implement these is way beyond the scope of an answer here unfortunately. It all depends on the details.