# Retrieve Alerts by Pull, Acknowledge Them, and Submit Outcomes
source: https://developer.mastercard.com/ethoca-alerts-for-merchants/documentation/use-cases/pull-alert-processing/index.md

## Context {#context}

This use case applies when a direct merchant or partner wants to retrieve queued alerts from the Mastercard-hosted API instead of receiving them through a webhook. It is useful when your platform prefers scheduled retrieval, controlled batching, or centralized API polling.

## Goal {#goal}

Retrieve unacknowledged alerts from Ethoca, confirm that your system accepted them for processing, and then submit the final transaction outcome after your investigation is complete.

## Actors {#actors}

* Issuer
* Ethoca Alerts platform
* Direct merchant or partner API client
* Merchant operations or fraud systems

## Outcome {#outcome}

The merchant retrieves available alerts, acknowledges them, reviews the affected transactions, and reports the final outcome back to Ethoca.

## Preconditions {#preconditions}

* Your organization is onboarded to Ethoca Alerts.
* Your account is configured for Pull retrieval.
* You have Sandbox or Production OAuth 1.0a credentials.
* Your client can call the Pull and Outcome APIs.

## Flow {#flow}

Diagram pull-alert-processing

### Step 1: Retrieve unacknowledged alerts {#step-1-retrieve-unacknowledged-alerts}

Call `GET /alerts` to retrieve alerts that have not yet been acknowledged by your system. This endpoint is the entry point for the Pull model because it lets you filter and batch alerts according to the operational needs of your merchant workflow.

API Reference: `GET /alerts`

### Step 2: Acknowledge receipt of the pulled alerts {#step-2-acknowledge-receipt-of-the-pulled-alerts}

After your system accepts the retrieved alerts, call `POST /alerts/acknowledges` to confirm receipt. This tells Ethoca that the alerts were successfully collected and should no longer remain in the unacknowledged queue.

Use this endpoint immediately after successful retrieval so the issuer can see that the alert was delivered to the merchant side of the workflow.

API Reference: `POST /alerts/acknowledges`

### Step 3: Submit the merchant outcome {#step-3-submit-the-merchant-outcome}

Once the transaction review is complete, call `POST /outcomes` to report the business result for each alert. This is the step that communicates whether the transaction was stopped, resolved, refunded, or otherwise handled.

API Reference: `POST /outcomes`

## Why These Endpoints {#why-these-endpoints}

* `GET /alerts` is required because Pull integrations start by retrieving queued alerts from Ethoca.
* `POST /alerts/acknowledges` is required because Pull retrieval is not complete until the merchant confirms receipt of the returned alerts.
* `POST /outcomes` is required because the issuer still needs the merchant's final decision after the alert is processed.
* No Push endpoint is used in this flow because the merchant, not Ethoca, initiates alert retrieval.