mailerlite / mailerlite-go

Go SDK for MailerLite
MIT License
3 stars 3 forks source link

Campaign scheduling function ignrores TimezoneID #11

Closed wilburx9 closed 1 year ago

wilburx9 commented 1 year ago

I suspect this is an issue with the web service (not this Go client) but I am raising this here with the hope that it gets escalated to the right team.

Take a look at this function.

According to the API docs, the timezone_id "Must be a valid timezone id, defaults to the account's timezone id". This means it will use the timezone id if it's passed, otherwise, it will use the account's timezone.

On the dashboard, update your account time zone to any that is ahead of UTC; e.g. "Asia/Tokyo".

Now, if you call the campaign scheduling function as I did above, and pass 426 (UTC) to TimezoneID (assuming you execute the program on a machine with UTC time zone), the call with fail with:

POST https://connect.mailerlite.com/api/campaigns/${CAMPAIGN_ID}/schedule: 422 Please select time in the future map[schedule.hours:[Please select time in the future]].

However, if you change the timezone on the dashboard to UTC, the API succeeds.

jtarrio commented 1 year ago

That's because the field is actually timezone, not timezone_id. I raised this with the team previously and they've acknowledged it, so I expect the fix will be published soon. For now I'm using a forked version of mailerlite-go with the correct field name.

wilburx9 commented 1 year ago

@jtarrio so you're saying both the docs and mailerlite-go are using the wrong field name?

jtarrio commented 1 year ago

That's correct. I had the same issue with the timezone, where it seemed to be ignored, then I tried using timezone instead of timezone_id as the field, and that worked.

The API reference is not generated automatically from the API definitions, so it is not complete and it contains mistakes. For example, the API reference doesn't tell you that, when you create a campaign, you can specify the plain text version of the email using the plain_text field.

robgordon89 commented 1 year ago

I can confirm that this has been fixed in the upstream API.

Please use timezone_id now 👍