It really depends upon what you intend to do with that printout. If you're printing a physical document for a user then how do they get the document. Your web server could be hosted on premise or the cloud. It might or might not have access to a printer near the person who needs it. In most cases the better solution is to do the printing client side. You can write javascript to print a batch of PDFs on the printer(s) available to the client. This eliminates the need for server-side printing. Of course the user could also just open the PDF and print from their PDF viewer as well.
If you need to print the PDF so you can manipulate them then don't bother printing, just use a PDF library like iText or equivalent and do your PDF manipulation.
If you really need to print a PDF to a printer then, ignoring the issue of the printer not being accessible, you'll want to move the process out of band. In the few cases where I've needed to do this we created a simple console app that did the printing. The console app was run using the Process task but it ran using credentials of a local user which ensured the local printers on the machine were used. Of course this has bad performance since starting a process with an interactive user is going to be slow (relatively speaking). You could also create a console app that hosts a WCF service (or if you're using .NET Core then hosting Kestrel directly) that your API then communicates with. The console app would need to be started when the server starts but shouldn't really be a Windows service since that is not supported either. There are loads of problems with this approach but it helps perf a little bit.
Finally the best option, in my opinion, is to write a batching processor that runs periodically (via scheduled tasks perhaps). The API would simply add the print request to some shared queue (probably a database or messaging queue). The batching processor, when it runs, would pick up things to print and then print them. If using a database then the processor could update the status when done. The API would provide a corresponding endpoint to check the status of the printing so the user could be notified (if relevant). Note that the API would not want to wait on the printing to complete as it could take longer than a web request. This is what the 202 HTTP status code is for - I've started the processing but I'm not done yet, here's some ID that you can use to query for the completion status later.