# Event types
source: https://developer.mastercard.com/open-finance-data/documentation/developer-support/event-notifications/event-types/index.md

This page outlines the various webhook event types you may receive when integrating with our Open Finance APIs.

The webhook endpoint definition, required headers (signature and replay protection), and the full payload schemas and examples are maintained in the OpenAPI specification, see [Payload Specification and Examples](https://developer.mastercard.com/open-finance-data/documentation/developer-support/event-notifications/event-types/index.md#payload-specification-and-examples).

All notifications follow the [CloudEvents standard](https://cloudevents.io/) (with a small set of product-specific attributes). Use the `type` attribute to route each event and process the corresponding `data` payload.

### Event Types Summary {#event-types-summary}

|         **Event type (`type`)**         |                                                                                                                                             **When is this event triggered?**                                                                                                                                              |                                                                                                                                                                                                 **What to do when you receive this?**                                                                                                                                                                                                  |
|-----------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `obdata.accounts.modified`              | Triggered when account details (balances, holders) are updated, or when an account's status changes as part of refresh operations.                                                                                                                                                                                         | Fetch the updated account data (for example, via **Get Account** or **Get Accounts**) and update cached balances/metadata. If status changed, propagate the new status to downstream systems.                                                                                                                                                                                                                                          |
| `obdata.transactions.modified`          | Triggered when transaction retrieval from the provider is complete for the initial data access. Thereafter, triggered when new transactions are detected or existing transactions are updated during regular syncs.                                                                                                        | Transactional data for the specified account has been updated. Invoke **Get Transactions** (or **Get Accounts**) to retrieve the latest data and update your local cache/state.                                                                                                                                                                                                                                                        |
| `obdata.consent.modified`               | Triggered when a consent transitions (for example, from **ACTIVE** to **INACTIVE** ). **Note:** Consent status webhooks do not currently notify the initial transition from **PENDING** to **ACTIVE**. To determine whether a newly created consent has become active, use the recommended polling method described below. | **INACTIVE:** Cease data retrieval and mark the consent inactive in your system. Initiate any retention/purge workflow consistent with your policies. Avoid further calls that assume the consent is active.                                                                                                                                                                                                                           |
| `obdata.connection.modified`            | Triggered on connection status transitions (for example: **ACTIVE** to **EXPIRED**).                                                                                                                                                                                                                                       | **EXPIRED:** prompt the end user to reauthenticate when contextually appropriate. **ACTIVE (after reauth):** resume scheduled refresh processing. **REVOKED:** stop refresh attempts and mark related data flows inactive. **FAILED:** an error ocurred with the connection check reason and/or contact customer support. **TERMINATED** the data-sharing period has ended, connection can no longer be extended via reauthentication. |
| `obdata.connection.expiration_reminder` | Triggered ahead of a known connection expiration (for example, 7 days before).                                                                                                                                                                                                                                             | Schedule or surface a reauthentication prompt, ideally while the user is active so the connection does not lapse.                                                                                                                                                                                                                                                                                                                      |

### Determining consent completion and account information readiness {#determining-consent-completion-and-account-information-readiness}

The end-user redirect at the end of a consent flow should not be treated as the sole indicator that the consent journey has completed. In some cases, the redirect back to the partner application may not occur, even though the underlying authorisation has completed successfully.
Partners should therefore use API polling as the fallback mechanism to determine when a consent becomes active.

**Recommended method**

Poll the **Get Consent** endpoint and wait until: `consent.endusers.connections.status = ACTIVE`

When the connection status becomes **ACTIVE**, the consent has been successfully authorised and the connection can be used to request account information from the provider.
Note: Important: An **ACTIVE** connection status confirms that the consent is active. It does not guarantee that account information is immediately available. Initial data retrieval may still be running in the background after the consent becomes active.

**Alternative method**

Poll the Get Managed Flow endpoint and wait until: `status.code = COMPLETED`
This method is supported; however, polling the connection status via Get Consent is preferred, as it provides the clearest and most authoritative indication that the consent connection is active.

**When the end user does not return to the partner application**

This guidance also applies when the end user does not return to the partner application after completing, abandoning, or timing out during the consent journey. In these scenarios, partners should rely on API polling rather than the redirect outcome.
If the consent remains in a pending state beyond the consent flow timeout period, partners should stop polling and treat the flow as incomplete or abandoned. The system timeout period is fifteen minutes.

**Licence scenarios**

This principle applies to both our-licence and customer-licence scenarios. The API status is the authoritative signal for determining whether a consent connection is active.

### Payload Specification and Examples {#payload-specification-and-examples}


API Specification: `https://static.developer.mastercard.com/content/open-finance-data/swagger/data-webhooks.yaml`