Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Unsubscribe API responses different behaviour and missing params #390
I am trying two ways to get the list of unsuscribes for a domain, but I found diferent behaviours calling to different ways (which is pretty inconsistent):
If you check the unsubscribe API index in API agnostic documentation:
But if you check the source code in PHP API you will see:
But there are even more problems, which is is the way of how is returned the data from Mailgun\Model\Suppression\Unsubscribe\IndexResponse
Instead if I call via:
Also since each item returned is an object of Mailgun/Model/Suppression/Unsubscribe/Unsubscribe, I notice which is missing the "id" fields which appears if you get only as json object via $mailgun->get('example.com/unsubscribes'); and the tag is returned as NULL instead "*" (which means all).
Waiting your reply, thanks
This was referenced
Aug 30, 2017
@Nyholm For point 1, I still need know which is the really limit number by the server specification, could you ask to the server guys? Which worry me more, it is how Mailgun flow is when the server spec changes things and the SDK clients receive the notification with changes for update properly? If not a clear way, a lot could be missing with the time if nobody detects
No, I have as much contact with "the server guys" as you have. ;) I do not work at Mailgun.
True, I would argue that it is a BC break to reduce the upper limit. Calls that previously returned 200 will now return 400. That is no good..
What do you suggest we should do? Maybe we should remove the client verification for this endpoint at let the server return the failure?
That's not a good thing :( Communication is the key. I was thinking that as Collaborator you was in contact with some representative, even if you are a freelance hired for them, the probably should help or designate to someone to speak with server guy-sdk relation.
Exactly. A silent BC from server
The should provide a changelog or show from specs or server changes in behaviour. So all SDK could adapt quickly based on that server changelog. The right thing should know the exact limit and raise an exception when the limits are reached previously to make the call. Imagine if you call 1000 times to that, and exception could stop you and avoid 999 calls more to the server, even you can catch the exception and treat properly if needed