Difference Between "recipient.type": "aep" and "external" in Transactional Messaging API

[TapanSaikia]

Hi team,

While working with the Transactional Messaging API (/ajo/im/executions/unitary), I noticed that the recipients array supports both "type": "aep" and "type": "external".

From my understanding:

• "aep" is used when the recipient exists in the Real-Time Customer Profile (RTCP) and the system can resolve the namespace (like Email or ECID).

• "external" seems to be for sending messages to users not stored in AEP, but I couldn’t find clear documentation on what data is honored in this case (e.g., profile attributes, channelData, or context).

Could someone please clarify the following?

1. What is the exact use case for "recipient.type": "external"?

2. Does the transactional API honor the "channelData.emailAddress" when "type": "external" is used, or does it still rely on any profile lookup?

3. Can dynamic headers like From Name and From Email be populated from the request payload for external recipients?

4. Are there any limitations or prerequisites (e.g., specific channel presets or message configurations) when using "external" recipients?

Thanks in advance!

— Tapan

[Anuhya-Y]

@TapanSaikia 

Using type as AEP, one should be able to send transactional campaigns for both:

• Profiles already existing in AEP, and

• Profiles not existing in AEP (in this case, new recipients/customers will be created as profiles in AEP on the fly).

I have not used the external option type, as type AEP already covers both use cases , existing recipients and newly created recipients.

The channelData parameter is used to replace the userId in the payload.

For example:

userId: abc@company.com

channelData.emailAddress: abc@gmail.com

Here, the profile is fetched based on the userId (abc@company.com), but the email will be sent to abc@gmail.com.

• If the profile already exists in AEP → no need to include channelData.emailAddress.

• If the profile does not exist in AEP → channelData must be passed in the payload. (new profile will be created on the fly based on channel data)

The From Name and From Email will be populated based on the email channel configuration, applicable to both existing and newly created (external) recipients.

[TapanSaikia]

Hi @Anuhya-Y , thanks for clarifying — yes, using type AEP does cover both cases.

What I’m trying to explore is whether it’s possible to populate header configurations like From Name and From Email dynamically from the context object in the API request payload, rather than fetching them from the profile.

Since the AEP type requires the profile to exist (or be created) in AEP, I was wondering if using type: external might allow us to pass these sender details (from name / address) directly in the request payload — without having to store them in the profile data.

[Anuhya-Y]

@TapanSaikia 

From Name and From Email are fetched only from the email channel configuration:
https://experienceleague.adobe.com/en/docs/journey-optimizer-learn/tutorials/configuration/channel-c... 

Neither the context object nor profile data is used for these fields in Transactional Messaging API.

[DavidKangni]

Hi @TapanSaikia 

type:external is a feature available only to limited organization. When enable, this feature will be able to send out emails to those end-users who don’t have any profiles in AEP. In addition, this feature would not create any new profiles if no profiles exist for the targeted end-user.

The steps listed below should be followed with this feature:

• Uncheck create new profiles.
• Uncheck both “track email opens” & “track clicks on links and buttons in email”.
• Type in API call should be passed as “external”.

Please keep in mind that if any of the options mentioned in steps 1 & 2 is enabled, a new profile will be created in AEP if it does not exist.

Reporting:

• Only Live report (24 hours) will be available in Campaign UI. This report will help us understand the number of emails were targeted and went out successfully. No tracking metrics would be available as it requires the profiles to be stored in AEP.
• The historical data of live report will be available under the dataset “AJO IM Passthrough Message Feedback Dataset” which is available in datalake, as well.

1. Does the transactional API honor the "channelData.emailAddress" when "type": "external" is used, or does it still rely on any profile lookup?
   [David]: Yes payload structure remains the same 

2. Can dynamic headers like From Name and From Email be populated from the request payload for external recipients?
   [David]: for both types NO

3. Are there any limitations or prerequisites (e.g., specific channel presets or message configurations) when using "external" recipients?
   [David]: check above. There is also a year volume limitation but you need to check with your CSM. 

I don't know if the feature still exists and available for new enablement but I used it.

Thanks,

David