Template Section IDs / Names
Since a few days, the sections list (for example https://api.mailjet.com/v3/REST/template?EditMode=3&Limit=1000) does not return the name anymore, it returns now a hash name like 70b8f864-6c33-4cb2-9605-88d74f06ddd. There are no documentations regarding this change. It seems that the Description now returns the name, but the description is missing? Could some of the mailjet developers please adjust documentations and inform about that change? Even the docs are not updated https://dev.mailjet.com/email/reference/templates#v3_get_template this is a break in the api and information's would be welcome.
(we are only intrested in gathering sections, i can not say whether the problem exists also for "templates")
thanks
ps: i posted this here, because the support does not answer since days regarding this. Also for technical persons this should be announced somewhere
Hello @nadar Thank you, I will let know the team about updating this in the documentation
@nadar I have a question for you. Could you post a code, that you use for getting info, please ?
I tested and have next results
Here is my code
$mj = new \Mailjet\Client(
'xxx',
'xxx',
true,
['version' => 'v3']
);
$response = $mj->get(Resources::$Template);
print_r($response->getData());
And here is my response
[0] => Array
(
[ID] => xxx
[OwnerId] => xxx
[EditMode] => 1
[Name] => test temp
[Locale] => en_US
[Author] => Oleksandr Mykhailenko
[Presets] => {"h1":{"fontFamily":"Arial"},"h2":{"fontFamily":"Arial"},"h3":{"fontFamily":"Arial"},"p":{"fontFamily":"Arial"},"a":{"fontFamily":"Arial"}}
[Previews] => Array
(
[0] => 319512922
)
[OwnerType] => user
[Copyright] => Mailjet
[Description] =>
[Purposes] => Array
(
[0] => transactional
)
[Categories] => Array
(
[0] => full
)
[IsStarred] =>
[IsTextPartGenerationEnabled] => 1
[CreatedAt] => 2022-06-02T21:28:53Z
[LastUpdatedAt] => 2022-06-02T21:29:10Z
[LocaleList] => Array
(
[0] => en_US
)
)
And I do not see any hash data that you wrote about
Sure, but your where retrieving a template, try to retrieve a section, therefore use ?EditMode=3 here is an example response for the request https://api.mailjet.com/v3/REST/template?EditMode=3&Limit=1000 (made via PostMan):
{
"Count": 283,
"Data": [
{
"ID": 111111111,
"OwnerId": 111111111,
"EditMode": 3,
"Name": "6d3e9729-0c94-49bf-b237-8af41201df9c",
"Locale": "de_DE",
"Author": "",
"Presets": "{\"h1\":{\"fontFamily\":\"Arial\"},\"h2\":{\"fontFamily\":\"Arial\"},\"h3\":{\"fontFamily\":\"Arial\"},\"p\":{\"fontFamily\":\"Arial\"},\"a\":{\"fontFamily\":\"Arial\"}}",
"Previews": [],
"OwnerType": "apikey",
"Copyright": "",
"Description": "Exampleexample ....... (08.04.2022) #3963352",
"Purposes": [],
"Categories": [],
"IsStarred": false,
"IsTextPartGenerationEnabled": false,
"CreatedAt": "2022-07-07T17:18:35Z",
"LastUpdatedAt": "2022-07-29T12:57:47Z",
"LocaleList": [
"de_DE"
]
}
}
Its about sections (EditMode=3), we create sections via API and retrieve them again (for the sync process).
Sure, but your where retrieving a template, try to retrieve a section, therefore use
?EditMode=3here is an example response for the requesthttps://api.mailjet.com/v3/REST/template?EditMode=3&Limit=1000(made via PostMan):{ "Count": 283, "Data": [ { "ID": 111111111, "OwnerId": 111111111, "EditMode": 3, "Name": "6d3e9729-0c94-49bf-b237-8af41201df9c", "Locale": "de_DE", "Author": "", "Presets": "{\"h1\":{\"fontFamily\":\"Arial\"},\"h2\":{\"fontFamily\":\"Arial\"},\"h3\":{\"fontFamily\":\"Arial\"},\"p\":{\"fontFamily\":\"Arial\"},\"a\":{\"fontFamily\":\"Arial\"}}", "Previews": [], "OwnerType": "apikey", "Copyright": "", "Description": "Exampleexample ....... (08.04.2022) #3963352", "Purposes": [], "Categories": [], "IsStarred": false, "IsTextPartGenerationEnabled": false, "CreatedAt": "2022-07-07T17:18:35Z", "LastUpdatedAt": "2022-07-29T12:57:47Z", "LocaleList": [ "de_DE" ] } }Its about sections (EditMode=3), we create sections via API and retrieve them again (for the sync process).
Oh, I see, thank you. I will try this way
Hello @nadar I tried next code
$response = $mj->get(Resources::$Template, ['filters' => ['EditMode' => 3]]);
print_r($response->getBody());
And have next results

Name looks fine for me. Are you sure you have a correct name for your section ? Maybe you created it with that hash before ?
And what if you create that section by API?
https://github.com/luyadev/luya-mailjet/blob/master/src/Sections.php#L66-L106
And what if you create that section by API?
Here is my code
$body = [
'Author' => "John Doe",
'Categories' => ['basic'],
'Copyright' => "Mailjet",
'Description' => "Used to send out promo codes.",
'EditMode' => 3,
'IsStarred' => false,
'IsTextPartGenerationEnabled' => true,
'Locale' => "en_US",
'Name' => ' My new custom section',
];
$response = $mj->post(Resources::$Template, ['body' => $body]);
print_r($response->getReasonPhrase());
print_r($response->getData());
And results;

So the name of section is not hashed in my example.
Did you debug what $name do you have before request ?
thank you @oleksandr-mykhailenko for your quick reply, i appreciated that a lot!
Yes, i am 100% sure we don't put hashed names (looks like uuid v4 to me) :-) We have the same sync process running since weeks, and it has changed since mailjet announced something about changeing IDs (https://documentation.mailjet.com/hc/de/articles/8821289909147 - sorry i don't have the english article) - so maybe older sections have been migrated to those names for no reason.
thank you @oleksandr-mykhailenko for your quick reply, i appreciated that a lot!
Yes, i am 100% sure we don't put hashed names (looks like uuid v4 to me) :-) We have the same sync process running since weeks, and it has changed since mailjet announced something about changeing IDs (https://documentation.mailjet.com/hc/de/articles/8821289909147 - sorry i don't have the english article) - so maybe older sections have been migrated to those names for no reason.
Oh, I'm not aware of such changes. So I will ask the team about it, looks like it's something on server, not inside the library. When I have an answer I will write here anyway. So it's on my radar
Thanks. Yes indeed, it has nothing to do with this library, but the support usually does not reply (or takes months) on technical issues, so i decided to post it here.
Thanks. Yes indeed, it has nothing to do with this library, but the support usually does not reply (or takes months) on technical issues, so i decided to post it here.
Oh, I see.
So I created a ticket to the technical team about that and found that it the same ticket was registered some time ago. So looks like they are aware of this. Hope, we will have answer soon
@oleksandr-mykhailenko Today we got from the support a very interesting answer regarding "this" thread. Something i can not really believe its true :smile: its translated from german to english:
Recently we made changes to our API and gallery template management. Now the gallery has a higher priority than the API. So when you delete a template/section via the API, you are not deleting it from the gallery as you would have done until a few weeks ago. However, deleting from the gallery deletes from there as well as the v3/template API endpoint.
So in other words, this means, that if you delete a section via API. It will still appear in the passport sections gallery.... ? it's a joke right? Can you confirm this? If this is true, the delete endpoint should be removed from the API because its useless and maybe this is also why i have hashed names section cause ... cause ... cause they are existing twice(?)..
This answer confused me. So I do not have answer for now but I will check this behavior. So I will check and let you know about this. Sounds weird
Hello @nadar
So I made a test about this. Here is my results So I have 2 saved sections

I made a request and got details about section

Next step is delete request
$response = $mj->delete(Resources::$Template, ['id' => $templateId]);
print_r($response->getBody());
print_r($response->getData());
print_r($response->getStatus());
print_r($response->getReasonPhrase());
Here is results from my print_r()

When I tried to get my sections again I got this

But I my account I have next results

So delete endpoint does not work for sections
So, i hope you agree, this is considered very very strange behavior and a bug :smile: Thanks for you research, and help on this. The support just closed my tickets... without a reasonable answer.
- you can list sections via api
- you can delete sections via api
- the sections are not visible anymore via api
- BUT the sections are visible in the UI
Then the whole api should be removed - or even better, fixing what its supposed to do :-) Can you create an internal ticket?
So, i hope you agree, this is considered very very strange behavior and a bug smile Thanks for you research, and help on this. The support just closed my tickets... without a reasonable answer.
- you can list sections via api
- you can delete sections via api
- the sections are not visible anymore via api
- BUT the sections are visible in the UI
Then the whole api should be removed - or even better, fixing what its supposed to do :-) Can you create an internal ticket?
Yes, I personally, agree with you. API does not execute logic that was intended. I will create an internal ticket
Hello @nadar I had a conversation with internal team and they explained to me how it works. So I only need to double check one things and will have an answer to you. I think, I will have an answer this week
Hello @nadar So I've got a response, and issue that you had was on during update functionality and it was fixed already.
Indeed, the DELETE endpoint from Template API will delete from Global DB and not Passport DB so the template should still be visible in Passport
So, so small portion of customers had issues, but it was fixed too. This is what I have for you
@oleksandr-mykhailenko thank you very much for taking care of this issue, also for asking internally what should be the right behavior.
I have to admit, i am not sure i understood correctly: It should now be possible again to delete sections, it was a bug? Because i just tested to delete a section, it does not disappear from passport, but from API. Nothing has changed.
@nadar it wasn't a bug, what I understand. Support told that some customers had issues, but they were resolved
@nadar What I can say for now, I do not have a full answer about your specific case, because I do not have access to see so much info. I can suggest to create a support ticket again, if you have question about your account , and they should help to you. Because I can think only from code perspective side
Thankfully you made an example here => https://github.com/mailjet/mailjet-apiv3-php/issues/260#issuecomment-1279154049 and you confirmed that its not possible to delete the section via api. So you can just re run your test and check that its still the same. Nothing has changed
So, as i can understand, you can not help me anymore, the support does not help anyhow, they just close the ticket, and the chat with the developers you had does not "answer" the origin question (they should fix that behavior i would suggest :smile:). So i can send a PR to the PHP SDK to remove the delete option, cause it does not work. agree?
Thanks for all your time taking care of this, we really appreciate that! Its really a pain (and also must be a pain for you). The introduced change is a huge break for services implementing the Mailjet API without any announcement or deprecation information.
@nadar We do not need to delete any API here. the library does not have a problem. I already asked internal team for having more detailed description of current behavior. So I hope, in a few future days I will get it and attach here
So, I did not get more detailed response about that. What I can tell for now, that delete functionality works in this way.
Thanks @oleksandr-mykhailenko for at least trying to find an answer. The mailjet api in terms of sections is absolute broken, i would no one recommend to use that :skull: . Since this issue is closed my last summary:
- its not possible to delete sections via api
- the api endpoint is documented in the official docs of mailjet
- developers from mailjet like @oleksandr-mykhailenko confirm the issue and can reproduce that.
- no one cares about, issue gets closed... Mailjet developers don't reply. Support tickets just get closed without any answer. They just don't care.