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:
Accept your transaction and return a
ticketIdimmediatelyProcess the transaction asynchronously
Send POST requests to your webhook URL as the transaction status changes
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
errorsfield 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: trueand acallbackUrlis providedThe webhook URL must be publicly accessible (not localhost unless using ngrok or similar)
Webhooks may arrive out of order - always check the
updatedAttimestampMultiple webhooks may be sent for the same status - implement idempotency
Webhook delivery is not guaranteed - implement fallback polling for critical transactions
The
tx_idfield will be empty until the transaction reaches SUCCESS statusAlways respond quickly to webhooks (< 5 seconds) to avoid timeouts
See Also
Transfer - Create and broadcast transactions
Transfer Multi - Advanced transfers with multiple inputs
Submit Raw Transaction - Submit pre-signed transactions
Get Transaction Status - Poll for transaction status
Last updated