Background and Foreground Aggregation

You cannot run a new aggregation within three hours of a successful aggregation, whether foreground or background. Pay attention to the aggregated_at and successfully_aggregated_at member fields while you’re developing your product with the API. We suggest that, if needed, you spread traffic to the API every three hours based on the user instead of running your entire platform.

Background Aggregation

MX automatically aggregates each member approximately every 24 hours. This process is called background aggregation. It ensures that end users' data is always up to date. This is beneficial because, if a background aggregation is successful (for example, the successfully_aggregated_at field indicates a time within the last 24 hours), you can choose to skip foreground aggregation and jump right to reading account and transaction data, which can help you load things faster in your product.

This background aggregation can be disabled by default for all members. Please reach out to MX to have this setting configured.

Background aggregation can be disabled or enabled for individual members by setting the background_aggregation_is_disabled field when creating or updating a member (or the disable_background_agg configuration option when using the Connect Widget).

Background aggregation is also disabled for members created when using the Connect Widget in verification mode. You can override this behavior by setting the disable_background_agg widget option to false. Note that this only affects newly created members.

There are a few other general rules related to background aggregation:

• The data source must allow background aggregation. Most sources do, but there are cases in which the data source does not.
• The member must not have been aggregated in the last 20 hours.
• The member must be in a CONNECTED, UPDATED, or CREATED state.

Foreground Aggregation

If an end user is present, you can choose to manually run a foreground aggregation. End users must be present during foreground aggregations because they may run into MFA, credential update requests, terms and conditions agreements, or other situations requiring end-user input. Just keep in mind that you cannot run a new aggregation within three hours of a successful aggregation, whether foreground or background. Thus, attention must be paid to the aggregated_at and successfully_aggregated_at member fields while you're developing your product with the Platform API.

info

Both foreground and background aggregation may be prevented by disabling a user. A user must be re-enabled before any aggregation can be attempted. We may suspend background aggregation on a particular member in some circumstances, such as when several consecutive aggregation attempts fail. However, you can always attempt a foreground aggregation on a suspended member.