Create an endpoint
First, choose a server environment, such as a cloud service like AWS, Google Cloud, or a self-hosted server, that supports receiving and processing webhook events or callback messages. Then, define an endpoint URL on your server where the webhook events and callback messages will be sent.Implement handling logic
After you create the endpoint, you need to implement the logic on the server to handle the webhook events or callback messages, including parsing the API request, verifying the signature, responding to the request and adding other handling logic if necessary.Verify the signature
To prevent unauthorized access, when you receive a webhook event or a callback message, you need to validate the authenticity of the API request by verifying the signature. The verification steps are as follows:-
Retrieve raw body and timestamp.
Extract the original body string from the request payload and the timestamp from the request headers.
-
Retrieve the signature.
Fetch the signature value from the request header.
-
Concatenate and hash the message.
-
Select Cobo’s Public Key.
Depending on the environment that you use, select the corresponding public key for verification:
- Development environment:
a04ea1d5fa8da71f1dcfccf972b9c4eba0a2d8aba1f6da26f49977b08a0d2718
- Production environment:
8d4a482641adb2a34b726f05827dba9a9653e5857469b8749052bf4458a86729
- Development environment:
-
Verify the signature using the Ed25519 algorithm.
Respond to the API request
Properly responding to webhook events and callback messages is crucial for ensuring that webhooks and callbacks are processed as expected. This section describes the expected response from both webhook and callback endpoints.Webhook events
When your webhook endpoint receives a webhook event, it should respond with a status code of200
or 201
to indicate that the event has been successfully received and processed. Once this response is sent, the WaaS service will stop retrying to send the event and the event status will become Delivered
on Cobo Portal.
The default timeout for each webhook event is 2 seconds. If the webhook endpoint does not respond or responds with a status code other than 200
or 201
, the WaaS service will continue to retry sending the event. If the number of retry attempts reaches 10 , the WaaS service will stop sending the event and the event status will become Failed
· You can resend the event by clicking Retry on Cobo Portal > Developer > WaaS 2.0 > Webhook Events.
Cobo does not guarantee that events will be delivered in the order they are generated. For example, creating a transfer will generate the following events:
wallets.transaction.created
wallets.transaction.updated
wallets.transaction.succeeded
Callback messages
When your callback endpoint receives a callback message, it should respond with a status code of200
or 201
and a response body of ok
or deny
to indicate transaction approval or rejection. Once this response is sent, the WaaS service will stop retrying to send the message and the callback message status will become Delivered
on Cobo Portal.
If the callback endpoint does not respond, responds with a status code other than 200
or 201
, or the response body does not contain ok
or deny
, the WaaS service will continue to retry sending the message. If the number of retry attempts reaches 30, the WaaS service will stop sending the message and the callback message status will become Failed
. You can resend the message by using the Retry callback message operation.
Code samples
To see examples of how to implement the handling logic, refer to the following files in the WaaS SDK GitHub repository:- Python: server_demo.py (implemented based on the FastAPI framework)
- Java: DemoController.java (implemented based on the SpringBoot framework)
- JavaScript: ServerDemo.js
- Go: server_demo.go
⚠️⚠️⚠️Important notes
- When receiving the webhook events, your endpoint should first return the correct status code promptly and then handle any subsequent processing asynchronously to prevent timeouts.
- Due to the retry mechanism of webhook events, webhook endpoints may sometimes receive the same event multiple times. To protect against duplicate event processing, please log the event IDs, transaction hashes, or transaction IDs you’ve already processed and refrain from processing those that are already logged.
Feel free to share your feedback to improve our documentation!