Callbacks

Receive payment and invoice notifications, acknowledge delivery and handle retries.

API v1 Integration Base URL https://coinzaka.com/api/v1

Examples use LTC unless stated otherwise. Use IDs and addresses for the selected currency.

On this page

#Payment Notifications

Available

Receive a notification when a payment is pending, confirmed or dropped. Callbacks use POST with a JSON body or GET with query parameters.

Parameters

Parameter	Type	Description	Required
`value`	integer	Observed amount in atomic units.	Required
`input_address`	string	Address that received the payment.	Required
`confirmations`	integer	Confirmation count at observation time.	Required
`input_transaction_hash`	string	Incoming blockchain transaction hash.	Required
`currency`	string	Payment currency identifier.	Required
`data`	object	Merchant metadata supplied with the callback configuration.	Optional
`account`	string	Public account identifier for account-scoped events.	Optional
`network`	string	Configured network of the currency, such as mainnet.	Required
`event`	string	Notified event: pending, confirmed or dropped.	Required
`status`	string	Receipt state when this attempt was built; after a delay it can differ from event.	Required
`event_kind`	string	utxo_output for BTC/LTC; trx_transfer, trx_internal or trc20_log for TRON; monero_output for XMR.	Required
`position`	integer	Output index (vout) or TRON event position within the transaction.	Required

{
  "account": "ACCOUNT_ID",
  "currency": "ltc",
  "value": 250000,
  "input_address": "LTC_ADDRESS",
  "confirmations": 1,
  "input_transaction_hash": "TRANSACTION_HASH",
  "network": "mainnet",
  "event": "confirmed",
  "status": "confirmed",
  "event_kind": "utxo_output",
  "position": 0,
  "data": {
    "order_id": "ORDER_ID"
  }
}

Replace placeholders in the JSON Request tab. Responses are illustrative.

#Acknowledgement and Retries

Available

Acknowledge payment and Simple Forwarding callbacks with HTTP 200, Content-Type text/plain and the exact body *ok*, including both asterisks.

Response part	Required value
Status	200
Content-Type	text/plain
Body	ok

Notes Acknowledge only after saving the event. Delivery is at least once; deduplicate repeated notifications. Failed receipt deliveries retry on each new processed BTC/LTC block through 255 confirmations, or every five TRON blocks through 20000 confirmations. The first delivery and worker-interrupted attempts remain eligible past the limit. A receipt's notifications stop after *ok*. Acknowledging pending means no confirmed event follows; to wait for confirmed, reply to pending with anything but *ok*. A pending not acknowledged by finality is superseded by confirmed. Dropped, and a pending that returns after it, are still sent. Dropped corrections use the same chain cadence with a window of 255 or 20000 blocks from first HTTP. BTC/LTC Simple Forwarding keeps its separate 0–6 confirmation window and 256-attempt budget; TRX and USDT forwarding notifications follow the receipt cadence above.

#Invoice Notifications

Available

Invoice events are sent to the callback URL as POST requests with a frozen JSON body. Changed receipts create a new revision even when the status name stays the same. Changes after an expired event remain in history without another notification.

Parameters

Parameter	Type	Description	Required
`account`	string	Public account identifier.	Required
`invoice`	string	Invoice identifier.	Required
`status`	string	Lifecycle state: created, partpaid, paid, overpaid, completed or expired.	Required

{
  "account": "ACCOUNT_ID",
  "invoice": "INVOICE_ID",
  "status": "paid"
}

Replace placeholders in the JSON Request tab. Responses are illustrative.

#Event Identity and Verification

Available

Use event headers to deduplicate deliveries and keep updates in order. Verify payment status before fulfilling an order.

Coinkun API v1