Forum Discussion
Liquid Date Formatting for API-Triggered Properties
I'm trying to format the date and time on our transactional appt confirmation emails. I found a formula that worked perfectly when I used a date field from Braze, but when I plug this same formula in...
Hi! Can you post the input date for both types of attributes, before the date filter is performed?
I tried this with both custom attributes and api trigger properties and I get the same result for both. As in, the right output prints in both cases, when using those date references.
It could be the original format of the date. You could try testing with the original inputs and if you still encounter the issue - try assigning both to new variables, instead of applying the date filter directly on the property.
The mly_first_job_date custom attribute is a Time field and both the job_promise_date and job_promise_time fields from the API properties are datetime2(7).
Let me know if that helps!
While the type might be datetime2 on the server side, the format it's in when it hits Braze MM/DD/YYYY is unsupported by the liquid date filter. The output you see is actually the input - none of the date operations you did with liquid were performed.
Ideally, you would reformat it in the backend and send it to Braze in an appropriate format. However, if you can't do that or if it takes too much time, here's a quick fix in Braze.You need to add this in the template. At the time the message is triggered, the code will reformat the variable to a date format accepted by liquid.
{% assign datevars = {{api_trigger_properties.${job_promise_date} | split: "/" }} %} {% assign monthsize = datevars[0] | size %} {% if monthsize == 1 %} {% assign month = datevars[0] | prepend: "0" %} {% else %} {% assign month = datevars[0] %} {% endif %} {% assign job_promise_date = datevars[2] | append: "-" | append: month | append: "-" | append: datevars[1] | date: "%A, %B %e, %Y" %} {{job_promise_date }}I'm not sure why the time liquid doesn't work though. I tried adding the same input and it worked for me. It would be helpful if you had logs of those API calls to see the actual values that are being passed.
