Transfer Webhooks

The MNEE SDK supports webhook callbacks for asynchronous transaction status updates. When you provide a `callbackUrl` in your transfer options, the MNEE API will send real-time status updates to your webhook endpoint as the transaction progresses through various states.

How It Works

When you initiate a transfer with a webhook URL, the API will:

  1. Accept your transaction and return a ticketId immediately

  2. Process the transaction asynchronously

  3. Send POST requests to your webhook URL as the transaction status changes

  4. Continue sending updates until the transaction reaches a final state (SUCCESS, MINED, or FAILED)

Webhook Response Format

Your webhook endpoint will receive a POST request with the following TransferWebhookResponse payload:

{
  id: string;              // The ticket ID for this transaction
  tx_id: string;           // The blockchain transaction ID
  tx_hex: string;          // The raw transaction hex
  action_requested: 'transfer';  // Always 'transfer' for MNEE transactions
  callback_url: string;    // Your webhook URL (for verification)
  status: 'BROADCASTING' | 'SUCCESS' | 'MINED' | 'FAILED';
  createdAt: string;       // ISO timestamp when ticket was created
  updatedAt: string;       // ISO timestamp of this update
  errors: string | null;   // Error details if status is FAILED
}

Status Flow

Transactions typically progress through these states:

  • BROADCASTING → Transaction is being broadcast to the network

  • SUCCESS → Transaction successfully broadcast and accepted by the network

  • MINED → Transaction has been mined into a block

  • FAILED → Transaction failed (check errors field for details)

Usage Examples

Basic Transfer With Webhook

Submit Raw Transaction With Webhook

Implementing a Webhook Endpoint

Express.js Example

Best Practices

1. Always Return 200 OK

Always return a 200 status code to acknowledge receipt, even if processing fails. This prevents the webhook from being retried unnecessarily.

2. Implement Idempotency

Webhooks may be sent multiple times for the same status. Design your handler to be idempotent:

3. Handle Timeouts Gracefully

Set up fallback polling for critical transactions in case webhooks fail:

4. Secure Your Endpoint

Implement security measures to protect your webhook endpoint:

5. Queue For Processing

For high-volume applications, queue webhook payloads for async processing:

Testing Webhooks

Local Development with ngrok

For local testing, use ngrok to expose your local server:

Test Webhook Server

Create a simple test server to log webhook calls:

Error Handling

Webhook Delivery Failures

If webhook delivery fails, you can still check transaction status using the ticket ID:

Handling Failed Transactions

When a webhook indicates a failed transaction:

Important Notes

  • Webhooks are only sent when broadcast: true and a callbackUrl is provided

  • The webhook URL must be publicly accessible (not localhost unless using ngrok or similar)

  • Webhooks may arrive out of order - always check the updatedAt timestamp

  • Multiple webhooks may be sent for the same status - implement idempotency

  • Webhook delivery is not guaranteed - implement fallback polling for critical transactions

  • The tx_id field will be empty until the transaction reaches SUCCESS status

  • Always respond quickly to webhooks (< 5 seconds) to avoid timeouts

See Also

Last updated