On-Premise API Change Notification Policy#
Melissa knows that no-one likes to have to update their code and push out an update at someone else’s schedule. However, we also all live in a fast-changing technological world where changes and updates are often necessary. Our goal is to provide the best user experience possible for our clients while keeping our cloud services as protected and secure as possible.
Our On-Premise API Policy is a bit different than our Cloud API as our users have more flexibility. We provide the API to our clients but it is up to the clients to schedule exactly when to apply it. This gives clients an extra layer of control and buffer on managing changes.
To make sure the right people receive change notifications:
Make sure your email is registered as a contact with Melissa. Your customer sales representative can assist with that.
Subscribe to opt in to release note update emails: https://releasenotes.melissa.com/subscribe/
Regular Update Changes#
As a subscription product, we regularly release updates to our data as well as engine. These changes are expected as a main feature of our products. We would not expect these changes to impact user’s code. They include:
Address coding differences
Email/Phone validation differences
Updates to underlying data version or engine
Engine Bug fixes
- Notification Period:
None, Email Advisory (opt in)
- Notification Channel:
Release Notes
Non-Breaking Changes#
Melissa continually strives to improve our products. If the opportunity presents itself for us to improve what we can offer to our clients, we usually choose to do so. These types of changes can include:
New output available
New Result Codes available (non-breaking)
Melissa result codes are designed so that we can add new codes and not affect our client code. If users want to take advantage of the new fields or new codes, they can simply alter their code to look for it.
- Notification Period:
None, Email Advisory (opt in)
- Notification Channel:
Release Notes
Operating System, Library, Language Support Change#
As technology evolves in the industry, Melissa will adapt and evolve our technology stack as well. This means that there will be technological advancements and changes required to keep up with ever evolving demands. These types of changes can be:
Removing support for deprecated operating systems
Removing support for deprecated library versions (ex: glibc)
Removing samples or older programming languages
- Notification Period:
6 months minimum, 12 months likely
- Notification Channel:
Release Notes, Email Advisory, Telephone communication
API Interface or Code Usage Changes#
As a last resort, we may need to make a change that would break code compatibility. They may include:
Removing or renaming an output field
Changing the meaning of a result code
Historically, Melissa have never pushed out a backwards compatibility breaking API Interface or code usage change. It is not in our interest to do so and we usually choose to add a new field or option.
- Notification Period:
6 months minimum, 12 months likely
- Notification Channel:
Release Notes, Email Advisory, Telephone communication
API Deprecation#
In the unlikely event that Melissa decides to deprecate an on-premise product, we will usually provide an alternative option. We typically provide our users the ability to continue to use the deprecated product for an extended period of time.
- Notification Period:
6 months minimum, 12 months likely
- Notification Channel:
Release Notes, Email Advisory, Telephone communication
- Exception:
Melissa does rely on third party sources (ex: the United States Postal Service) for data updates. While unprecedented, the remote possibility exists of a data vendor abruptly ceasing business operations with little or no notice. Under that scenario, we will provide users with immediate notice with a mitigation plan.