The short version is that you’d leverage WordPress’s HTTP API to acquire your data from the external API (or perhaps that service’s dedicated PHP library, if they provide one), then wp_insert_post() to insert that data into new posts. There is nothing unique about how you would register or handle an associated CPT to this end.
Assuming this was to be a sort of “synchronization routine” ran at regular intervals via WP_Cron or otherwise, you’d probably also want to store a timestamp for the last time data was synchronized, and only ask the remote API for content which is newer than that stamp (or more robustly, perhaps a few minutes before than that timestamp to account for potential edge-cases), using a piece of post meta to store the remote service’s identifier for that piece of data in order to prevent processing data into duplicate posts.
If the amount of incoming data is substantial enough that it risks running out the clock on PHP script execution limits, you’d probably want to queue up requests for smaller chunks and work through them using a background queues – Woo’s Action Scheduler is a pleasant way to accomplish this. It uses a technique of performing HTTP requests locally to the same installation, allowing it to execute whatever functionality within the WordPress environment independent of any front-end request, and cascade requests if necessary in order to handle long-running routines.
There’s probably a lot more which could be said on the subject, but the specifics of the implementation are heavily dependent on the actual use-case. Keeping the data in all posts synchronized with that in some external API is a whole other ball game, for instance, and would be heavily dependent on the functionality which the API offers.