Assuming that you mean Contacts in Sales Cloud:
Part of the answer depends on the load:
Journey Builder / Create Contact will have trouble when your list is in the thousands, then Bulk API would be the way to go.
It's a bit of a thing to get this done though:
Account Activity or Object Activity in Journey Builder has limits to update like Data Loader?
If the numbers are small, File Drop and injecting into Journey Builder could be viable option.
Part of the answer is not technical:
In many scenarios, I would disencourage such an import of unvalidated data "off the street" and advise a Double Opt In Journey in which you inject using SFMC generated Temp Ids before creating the contacts.
Viability depends of course on your business case - of course there will be a high drop-off rate.
In case you can do a DOI, you can address a lot of problems that you should also think about before setting up a Journey / Bulk API import.
- During DOI you can force logging of necessary metadata (when did you get the data, where from...)
- You ensure data quality (invalid emails don't confirm)
- Only those that confirm get sent to Sales Cloud as Contacts, saving you storage, keeping data quality high, and of course you can enforce a dupe check if & when each recipient confirms.
I cannot give any legal advice, but depending on your legislation, you might want to consult someone who can, if there are specific requirements you should meet or if you can just put data in your system and send emails.
If you cannot go for a DOI, you can basically stop reading now. Check your expected load, do some due diligence as for the points mentioned.
If you can go for DOI, then the following can help, back to some more technical viewpoint.
SQL newId() function can help generating "temp IDs".
concat('somePrefix_',newId()) AS myTempKey
If you use myTempKey in the Send Relationship for a double opt in sendout, you create a lot of Contacts, not checking for potential duplicates. So this is a problem you need to solve, which luckily is simple:
You'd have to delete all temp Ids after some defined time using Contact Deletion. See also:
Trying to automate contact deletion with SSJS
The sendout of the DOI Email puts your temp IDs on All Subscribers list, where they can easily be retrieved with sql. The 'somePrefix_' in the myTempKey field part makes it pretty simple to isolate all data that came in through your process.
WHERE SubscriberKey LIKE 'somePrefix_%'
AND //some date logic based on a creation timestamp
/* and then delete the data regularly */
From here, you'd have to think about your DOI confirmation, including dupe check, logging etc.
Not saying this is simple - but consider that if GDPR does apply to you in some shape or form, I would not be too quick in uploading data from somewhere without validating data, documenting and logging the process.
Hope this helps!