# Recieving Updates

This document provides **best practices for receiving Purchase and Deposit updates** from Inabit Terminal. It explains how to combine Webhooks (for instant notifications) with the GET API (for reconciliation and reliability).

**Goal:** A simple, reliable setup to receive purchase and deposit updates using both:

* `Webhooks` for instant notifications
* `GET API` backup for periodic reconciliation and gap-filling.

{% hint style="info" %}
The hybrid approach is the **recommended method for production**.
{% endhint %}

### 1) Why Hybrid?

* **Immediate** **updates**: Webhooks deliver events as they happen\
  (e.g. `IncomingTransactionReceived, PurchaseInitiated` ).
* **Resilient**: If a webhook is delayed, retried, or missed, the GET API fills the gap.
* **Accurate**: Regular API polling verifies totals, confirmations, and states.

### 2) Minimal Setup

#### Webhook  `push`

* Inabit Terminal sends an HTTPS POST for each deposit or purchase event.\
  (Refer to [webhooks](https://docs.inabit.com/inabit-terminal/api-reference/webhooks "mention"))
* Merchant endpoint should:
* **Validate JSON & schema**.
* **Respond with 2xx within 5s** after basic checks.
* **Enqueue** the event for asynchronous processing (avoid heavy logic in the webhook).
* **Retries**: If no 200 response is received, Inabit retries delivery.
* **Signature**: Support for signing will be added in future. In the meantime, merchants can validate by cross-checking the event using the **GET API by Purchase/Deposit ID endpoint**.

#### GET API  `pull`

* Poll events by **timestamp** (starting from the last processed event).
* Maintain a durable **checkpoint** (last handled timestamp).
* Recommended polling frequency: **every 2–3 minutes**.
* Use the **last timestamp** as the starting point and set the end time with \~1 minute delay to ensure no missed events.