Question

Transactional emails are not being sent with merge tags

  • 11 March 2024
  • 5 replies
  • 43 views
N

Hi there.

 

I’m on the startup program, but am running into a technical issue. Was advised to create a post here since the startup program does not give me direct access to support.

 

Essentially, when using the Python SDK, transactional API requests to send emails don’t always populate an email with merge tags that are accessible via attributes that exist on the customer. However, sending the same request through cURL does populate the email with correct merge tags!

 

Here is sample python code:

from customerio import APIClient, SendEmailRequest, CustomerIOException, Regions

api = APIClient(<API_KEY>, region=Regions.EU)

request = SendEmailRequest(
  transactional_message_id="verification-email",
  identifiers={
    "id": <EMAIL>
  },
  to=<EMAIL>
)

try:
  api.send_email(request)
except CustomerIOException as e:
  print("error: ", e)

 

And sample cURL code:

request='
{
  "transactional_message_id": "verification-email",
  "identifiers": {
    "email": <EMAIL>
  },
  "to": <EMAIL>
}
'

echo $request | curl -v https://api-eu.customer.io/v1/send/email \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer <API_KEY>' \
-d @-

 

Now I’ve noticed this issue is actually intermittent. Sometimes the SDK is sending the emails with correct merge tags. Other times it isn’t…

This is pretty critical since we’re losing potential customers due to them not receiving a correct verification email!

 

Is anyone else running into this issue? Or Technical Support -- please advise on how to fix, because this is pretty major

5 replies

R
Userlevel 2

Hi Nihir,

Thanks for reaching out here. 

Looking at your Python request, I see that you are using “id” as an identifier but using an email address as a reference. I’d recommend using “email” as the identifier for these requests and then hopefully that should make those requests more successful. I looked through out logs, and I was able to see that this was changed in later calls, and “email” appeared as an identifier, so I assume this is when it worked for you.

If you continue to run into problems, let us know more specifically where you’re seeing the issue in your transactional email, and we can take another look.

Thanks,

N

Hey @Ryan_cio.

 

If I was using “id” as an identifier, that was just some test code. Our actual backend code was using the “email” identifier. In both cases, this was failing to send the emails correctly.

 

However, I want to re-emphasise that this issue is intermittent. Sometimes the Python SDK is sending the emails with the correct merge tags. Other times it is not. I’m not sure what is causing the intermittent behaviour.

 

How do I tell you where I see the issue in the transaction email? Can you access parts of my account? If so, you’ll see that some emails to People are sent without the relevant merge tags, despite the merge tags being present in the transactional email template. When sending test emails via the email template builder, the merge tags are correctly populated for each person.

digitalisierungsprofi
Userlevel 1

@nihir I suspect that the differences in behavior could as well come from a slight delay with data flowing into c.io. If your confirmation email is triggered right at the moment of registration, the data that you are sending via “identify” API call might not be present yet. Although it’s near-realtime, it’s not instant.

So maybe it’s rather depending on this than whether you are using CURL or the Python SDK.. But that’s just a guess.

 

 

Anyway, if would pass along all relevant data that you are using in your email directly as part of the transactional email API call inside the “message_data” attribute, as you can see in those examples:

https://customer.io/docs/journeys/transactional-api-examples/

 

In your email, you then use the merge tag {{trigger.<your-data-object-property>}} instead of {{customer.xxyy}} to use the data that comes with the API call and are not depending on data being in c.io already. Think this makes it more bulletproof

Are you looking for a customer.io expert in Germany, Switzerland or Austria? Contact me on www.digitalisierungsprofi.ch and I'm happy to help you with setting up data tracking to c.io as well as complex use cases that leverage your customer data.
N

@nihir I suspect that the differences in behavior could as well come from a slight delay with data flowing into c.io. If your confirmation email is triggered right at the moment of registration, the data that you are sending via “identify” API call might not be present yet. Although it’s near-realtime, it’s not instant.

So maybe it’s rather depending on this than whether you are using CURL or the Python SDK.. But that’s just a guess.

 

 

Anyway, if would pass along all relevant data that you are using in your email directly as part of the transactional email API call inside the “message_data” attribute, as you can see in those examples:

https://customer.io/docs/journeys/transactional-api-examples/

 

In your email, you then use the merge tag {{trigger.<your-data-object-property>}} instead of {{customer.xxyy}} to use the data that comes with the API call and are not depending on data being in c.io already. Think this makes it more bulletproof

 

Hey -- this is a good theory. Thanks for sharing. Not sure it holds though. I’ve tested it asynchronously with myself as a customer and myself existing for a few hours before making the requests. Similarly it worked with cURL but not the Python SDK.

digitalisierungsprofi
Userlevel 1

@nihir thanks for your feedback. In any case, for such an important transactional email like your verification email i would switch to use data that you submit with your API request only.

Are you looking for a customer.io expert in Germany, Switzerland or Austria? Contact me on www.digitalisierungsprofi.ch and I'm happy to help you with setting up data tracking to c.io as well as complex use cases that leverage your customer data.

Reply


Terms & ConditionsCookie settings
Product
Resources
Industry
Company

Privacy PolicyTerms of ServiceStatus© Peaberry Software, Inc.