Contact key in transactional journey

Question

my use case is like this. I am getting data from GCP with unique id [external system ID] as subscriber key. suppose I have a subscriber [email protected] with subscriber key 12345. Now we have this transactional journey payload where we need to insert something as "contact key" : contactkey value, above contactkey value will be subscriber key in triggered send data extension which is entry source for journey.

when transactional email is sent then I want to know.

1. when we are triggering API payload from AWS , is there any option we can get subscriber key of [email protected] to use in payload or AWS team need to have those records with subscriber key value to use in Payload.
2. If they dont have [email protected] records subscriber key and uses some unique ID from AWS so does it will create duplicate record of [email protected] with this new unique ID as subscriber key.

How does above use case works. if any reference links or documents present please share

Answer 1

What you are dealing with here, is a clear case of your Subscriber Key not being global (i.e. present across all your systems). You would normally have a setup where your Subscriber/Contact Key (these are actually one and the same thing - Subscriber Key is however only present in Email Studio, while Contact Key is across all of SFMC) is known to all systems pushing data or triggering emails in Marketing Cloud.

If the only way for you to generate a new and unique subscriber key, is by using a GUID in SFMC, you will find it difficult to build a robust architecture, where all your integrations are able to utilise this subscriber key. Here is a good article on what is important when deciding on the right subscriber key, and why.

You COULD use SOAP API to first query the All Subscribers list to find the details about a subscriber, including subscriber key, based on the email address. This will need to be done before triggering the API call to the transactional API journey.

However this still leaves me with one major concern, and it is the issue of not having proper identity and consent management application and process in place. At least I'm not able to identify it based on your posts. This is indeed a topic which should not be underestimated, and requires proper solutioning effort by an experienced architect.