Identification events list

We inform the client of asynchronous event using webhooks. Whenever a new event occurs a HTTP call to your registered webhook URL will be perform. This payload will content all the information that you need to register this event. In this way the client receives in real time the information related of every event.

User identification events list

Every time a user try to verify his identity, a webhook is activated with these possible events:

Event	Description
identification_pending	Triggered when a user finish the identity process and is is pending of approval.
identification_verified	Triggered when the user's identity has been approved.
identification_rejected	Triggered when the user's identity has been rejected. The user is not permitted to use the platform and you should contact Depasify for a manual review.
identification_retry	When a file is altered or the selfies are not clear, the user is invited to submit the process again.

Accounts

We inform the client after every account is registered in our platform , a webhook is activated with these possible events:

Event	Description
account_created	Triggered when a account is created succesfully.
account_locked	Triggered when an account is blocked for any service.
account_unlocked	Triggered when an account is unblocked for any service

Fiat Payments

We inform the client after every transactions is registered in our platform. Here we can have these events:

Event	Description
fiat_payment_pending	Triggered when a fiat payment is requested for a `bank_account` and is awaiting processing.
fiat_payment_received	Triggered when a fiat payment for a `bank_account` is received in our platform
fiat_payment_sent	Triggered when a fiat payment for a `bank_account` is sent from our platform
fiat_payment_failed	Triggered when the fiat payment failed and it needs a retry.
fiat_payment_settled	Triggered when the fiat payment has been settled in our platform
fiat_payment_processing_refund	Triggered when the a payment refund has been requested in our platform

Blockchain payments

We inform the client after every transactions is registered in our platform. The next events can be occur:

Event	Description
blockchain_payment_received	Triggered when a payment or token has been received in any of your wallets
blockchain_payment_enqueued	Triggered when an outgoing payment has been accepted by Depasify, and it's enqueued for its further execution. This event doesn't yet contain a trx. id
blockchain_payment_sent	Triggered when an outgoing payment has been processed succesfully, and it contains its trx. id
blockchain_payment_failed	Triggered if the outgoing payment cannot be processed properly. These cases will need to review your Idempotent implementation and decided if re-try or create a new instance of the payment.

Trades

We inform the client after a trade is filled or pending in our platform. Here are the events

Event	Description
trade_pending	Triggered when a trade is requested and is await processing
trade_filled	Triggered when a trade has been processed correctly and its filled
trade_non_created	Triggered when a trade has been rejected

Daily Settlement

We inform the client after a daily settlement has been completed in our platform. Here is the event

Event	Description
daily_settlement_completed	Triggered when all the payments for a date have been settled

Card Payments

We inform the client after every transactions is registered in our platform. Here we can have these events:

Event	Description
card_payment_completed	Triggered when a card payment process is successfully captured and completed.
card_payment_failed	Triggered when a card payment capture is declined or fails for any reason.
card_payment_refunded	Triggered when a card payment refund has been confirmed by the payment provider.

All the JSON payloads contents of each possible event is detailed in the Webhook events and payloads section .

Tickets

We inform the client after every ticket activity is registered in our platform. Here are the events:

Event	Description
ticket.created	Triggered when a new support ticket is created.
ticket.status_changed	Triggered when a ticket's status changes (e.g., open → waiting_customer → resolved → closed).
ticket.new_message	Triggered when a staff member sends a new message on a ticket.

All the JSON payloads contents of each possible event is detailed in the Webhook events and payloads section

Retry policy

Our webhooks work with a retry policy so we make sure the information is received. Whenever a webhook is sent, we keep track of the status of the response we get to our HTTP call. If it is an error response, the webhook will automatically retry. It will retry up to 3 times until the response is successful. If it keeps failing, we store the information so we ensure that no information gets lost.

Ensuring Idempotency with the Idempotency-Key Header

To ensure idempotency in our API, we utilize the Idempotency-Key header. This header allows clients to assign a unique identifier to each request, ensuring that the same operation is not performed multiple times.