API Create Template

H

holgroup

Member
I have managed to figure out how to create templates using the API, sending key:value pairs to the API endpoint, successfully created the template name etc in the Mailwizz application, success = 201 and I get the unique templet ID back, however the HTML sent is being corrupted, even for a simply HTML test code:
<body><h1>Hello</h1></body>.

Response is:
{
"status": "success",
"template_uid": "kt6583oed87c0"
}

I have tried on postman as well, successfully creates template but again HTML in the template body is corrupted. I am sending Content-Type application/x-www-form-urlencoded; charset=UTF-8 and have tried without the charset UTF8 encoding as well. The full request is as follows, with URI and key obscured:
{
"uri": "https://[domain]/mailmanager/api/index.php/templates/create",
"method": "POST",
"headers": {
"X-Api-Key": "[key]",
"Content-Type": "application/x-www-form-urlencoded",
"Accept": "*/*",
"Accept-Encoding": "gzip, deflate, br"
},
"body": "template[name]=My%20API%20template1&template[content]=%3Cbody%3E%3Ch1%3EHello%3C%2Fh1%3E%3C%2Fbody%3E"
}

I get the template name correctly but the HTML is:
<body style="box-sizing: border-box; margin: 0;">?e
<title>
</title>
</body>

I have also tried Content-Type: application/json and text/plain and text/html and they fail with 422Unprocessable Entity (WebDAV) (RFC and if I try Content-Type = multipart/form-data I get 403Forbidden
 
FYI, I saw from the examples within the https://github.com/thangtx/mailwizzphpapi-wrap code on github that both "content" and "archive" elements need to be base64 encoded, so I tried that:
{
"uri": "https://[domain obscured]/mailmanager/api/index.php/templates/create",
"method": "POST",
"headers": {
"X-Api-Key": "[key obscured]",
"Content-Type": "application/x-www-form-urlencoded",
"Accept": "*/*",
"Accept-Encoding": "gzip, deflate, br"
},
"body": "template[name]=My%20API%20template1&template[content]=PGJvZHk+PGgxPkhlbGxvPC9oMT48L2JvZHk+&template[inline_css]=yes"
}

Again the HTTP call to the api returns sucess but within my template in the Mailwizz backend, I dont get an empty template with garbled characters I get some kind of default template (the one that gets loaded when you click "create new"). Now even more confused.
 
I thought maybe MW need a more meaty HTML template so I expanded my simplistic example to this:
<!DOCTYPE html>\n<html>\n<body>\n\n<h1>My First Heading</h1>\n<p>My first paragraph.</p>\n\n</body>\n</html>

If I inspect the mw_customer_email_template table in mySQL I can see the below in the content column:
<!DOCTYPE html?[????O???Dגf?'7B?VF??s???q????5䁙???Ё??Ʌ?Ʌ???????q?q???\n</html

I have checked the TemplatesController.php file and this appears to base64 decode the "content" field as passed into the API so this would make sense with the need to base64 encode, but still I get garbled templates which clearly the backend template editor cant handle so it gives up and loads the default "create new" template. Any ideas greatly appreciated please.
 
Okay the fact that I can see the DOCTYPE successfully but it all goes wrong when it hits special characters tells me I am going in the right direction. After URL-encoding the Base64 string before appending to the query string, I can still import the template successfully and finally I get legible text in the template editor and its what was expected:


<body style="box-sizing: border-box; margin: 0;">\n
<title>
</title>
\n\n\n
<h1 style="box-sizing: border-box;">My First Heading
</h1>
\n
<p style="box-sizing: border-box;">My first paragraph.
</p>
\n\n\n
</body>
 
Given that the API documentation is so basic and missing a lot of useful information, I am hoping my journey helps other novices.
 
Yes, perhaps so, but not when you are using an intermediate tool like PowerAutomate, or Zapier or Pipedream or Make to provide the middleware solution between Mailwizz and other business applications. In either case, improvements to the documentation would be more useful (particularly on the "content" or "archive" elements of passed fields) to people trying to work with the API than excuses from the development team.
It would also be useful to specify that calls to the rest API using an HTTP connector need to be passed as query string key:value pairs, encoded appropriately; just to save novice users from having to dig through all of the documentation themselves.
 
Since version 2.5.7 we added OpenAPI documentation for the API. There we specify that the content should be base64 encoded, In the api-docs since the examples are using the client, there is no need to do that.

Code: 
--- -------------------------------------------
--- Version 2.5.7 - 2024-07-18
--- -------------------------------------------
[ADD] - Added OpenAPI specs for the API (`/api/index.php/docs`)
 
ghimes said:
Since version 2.5.7 we added OpenAPI documentation for the API. There we specify that the content should be base64 encoded, In the api-docs since the examples are using the client, there is no need to do that.

Code: 
--- -------------------------------------------
--- Version 2.5.7 - 2024-07-18
--- -------------------------------------------
[ADD] - Added OpenAPI specs for the API (`/api/index.php/docs`)
Click to expand...
As always more excuses, I have just searched the API docs for "base64" and it doesnt appear:
1738828301200.png
 
In these parts, whereever the field "content" or "archive" is required, you should add a note to say "must be base64 encoded":
1738828392003.png
And in the "getting started" or the "setup" page it would have made it so much easier to remind people that in the key:value, that the value should be URI encoded before sending to the API, and that the base64 content and archive, once base64 encoded should also then be URI encoded as well. Many people will be using a "connector" type middleware process to move data between other applications and Mailwizz and this would have saved lots of time. The issue has come up before on the forums, it was only through dissecting the way the API code handled the incoming data that I was able to deduce this.
 
You must log in or register to reply here.
Back
Top