We made a variety of fixes to our Swagger spec to improve the documentation.

There were endpoints included in the documentation that have no function except to organize the path hierarchy. For example: /reporting. We removed them since they’re not useful on their own. Additionally, there were some body parameters included incorrectly, for properties that are read-only and can’t be passed in as a parameter

We updated our Swagger spec to make it match the spec used in the codegen repo.

We use a Swagger spec to produce API client libraries from the codegen repo. Doing this required tweaking the Swagger spec that’s automatically produced by our internal API definitions, so there was some drift between the spec in the codegen repo and the one we produce automatically. We backported the changes, so our automatically-produced spec matched the one in the codegen repo. Now that this work is done, we can rely on the automatically produced spec for client libraries.

We’ve stopped calculating the (deprecated) existing, options, and imports fields for the Growth History endpoint, and API responses will have a value of zero for these fields.

The data in these fields can be accessed in a more understandable way in other fields, and returning the data in these fields was slow and added infrastructure load when these endpoints were requested.

We have released API client libraries for the Marketing and Transactional APIs, supporting PHP, Node.js, Ruby, and Python.

We wanted to make it easier for developers to integrate their applications with both of our APIs in the language of their choice. The new libraries are generated from publicly available API specs and published on the respective package managers for each supported language.

It was possible to force multiple confirmation emails to be sent to a member when using identical PATCH or PUT requests to the Members resource. We’ve corrected this behavior by preventing the duplicate confirmation emails from being sent.

Before this change, multiple confirmation emails would be sent to a member’s inbox, which could potentially be used for abuse.

The security team has implemented stricter rules around redirect URL matching in our OAuth 2 implementation. We now only support exact matching on the redirect URI to adhere to the OAuth 2 spec.

Before this change, our redirect URL matching didn’t conform to the OAuth 2 spec. Strictly adhering to the spec results in more predictable behavior and fewer surprises.

We changed the behavior of the unsubscribe merge tag to obfuscate the email address of the person who clicked the link. Instead of showing the entire address, the md_email parameter now displays the address as something like x****@x***.*** .

Previously, if a customer clicked an unsubscribe link, their email address was displayed on the Unsubscribe page in full. By obfuscating the email address, this change provides better security.

Previously, if an object was passed as the value of the email field in a POST to the Lists/members endpoint, the server would return a 500 error. Now we return a 400 error with a clear error message.

We saw multiple occurrences of these errors in our logs. Ideally, badly formed requests shouldn’t return 500 errors, and we should give more information to callers when errors do occur.

We’ve updated our Swagger file to make it OAS 2-compliant. Our API Reference documentation is generated from our Swagger file. Before this change, we used a number of non-standard field names to control formatting in those docs. We cleaned those fields up and added testing to prevent drift in the future.

We’d heard from developers that an OAS 2-compliant Swagger would greatly improve the developer experience for the Marketing API. This update makes it possible, for example, to directly use our Swagger file in Postman to more easily make requests to our API endpoints, in addition to better integration with many other OAS-friendly tools.

Previously, null-valued entries in the properties object passed to the Events endpoint would cause a server error, returning a 500 to the client. With this change, we treat null property values as empty strings.

This change gives clients a little more flexibility with how they format the properties parameter, and it cleans up our server logs.