Most functionality within the platform relies on the latest Member
Values. Since Member Values are a time-series, it is possible to POST the same
information for a given member (e.g.
City=Vancouver) many times without noticeable functional
implications. Doing so will simply record that
City=Vancouver was known to be true at these several
points in time.
However, when you create a query using the
/membervalues/asof/{datetime} resource through that time
(including for
9999) the same information will always be returned. If
these distinct Member Values are not meaningful to you, then they create excess
data that can affect the performance of the API, particularly when using
/membervalues.
Whenever you have information on the actual
effectiveDate where a piece of information is known
(e.g. if the information was collected in a web form from a person on a
specific date), we recommend including
effectiveDate when posting the Member Values. This will
minimize storage of excess data and also assist in cases where information on a
member is collated from several sources (e.g. API integration + survey
responses) into this service.
effectiveDate. If this is the case, you may want to
record this information as the latest date for the member. In such cases, we
recommend the following workflow:
- Issue a GET call to
/membervalues/asof/9999to check the current information for that member. - If the correct information has not changed, then the POST can be avoided.