Skip to main content

​
February 2026

​
2026/02/27

Added request logs feature to help businesses monitor and debug API activity. View detailed logs of API requests made to Busha directly from your dashboard.What you can see:
  • Status code: HTTP response status
  • HTTP method: Request type
  • Endpoint: The specific API endpoint called
  • Request ID: Unique identifier for each request
  • Timestamp: Date of each request
Features:
  • Search by Request ID: Quickly find specific requests using the search bar
  • Filter options: Narrow down logs by various criteria
  • Pagination: Browse through your request history
  • Auto-refresh: Logs update automatically as new requests are made
How to access:Navigate to Settings → Developer Tools → Request Logs in your Busha dashboard.

​
2026/02/24

Introduced the reversal_policy field in quote object to control how cancelled/failed transfers are refunded.New field:
  • reversal_policy: An optional field set to "conversion_only" to refund the original source amount to the source balance in the event of a transfer failure. The field accepts conversion_only value for now.
For example:
{
  "source_currency": "USDT",
  "target_currency": "NGN",
  "source_amount": "100",
  "reversal_policy": "conversion_only", // refund the transfer back to USDT if the quote transfer fails.
  "pay_in": {
    "type": "address",
    "network": "SOL"
  },
  "pay_out": {
    "type": "bank_transfer",
    "recipient_id": "625syssysts8388"
  }
}
In the quote above, the originating transfer will refund the source amount of 100 to the business source (USDT) balance if the transfer goes into a refunded state either from cancellation or failure to complete its lifecycle.

​
2026/02/23

Added webhook event history and replay functionality in the Busha dashboard. Businesses can now view, monitor, and resend past webhook events for the last 21 days.Key features:
  • Event History: View all webhook events from the last 21 days with full request/response details
  • Manual Replay: Resend failed or missed webhook events directly from the dashboard
  • Search & Filter: Find specific events by reference ID, status, category, or date
  • Delivery Tracking: Monitor webhook delivery success and failure rates
  • Debugging Tools: Inspect exact payloads sent for troubleshooting integration issues
How to access: Navigate to Settings → Developer Tools → Webhooks in your Busha dashboard, then click on a webhook to view its activity log.

​
2026/02/18

All API endpoints now return a unique request identifier in the response headers under X-Request-Id. Request IDs help track specific API calls and expedite issue resolution when contacting Busha support.Key details:
  • Header name: X-Request-Id
  • Format: req_ prefix followed by alphanumeric string (e.g., req_JfPBXEC5rLHc)
  • Availability: All endpoints
  • Retention: 21 days
New guide: guides/request-id/request-id explains how to capture request IDs in your code and when to use them for debugging.Use request IDs to provide precise details when reporting API errors or unexpected behavior to Busha support.

​
2026/02/10

  • Page: guides/recipients/create-and-manage
  • Deleted legacy code examples that no longer match the current API surface. - Removed the deprecated X-BU-VERSION header from sample requests so developers copying the guide use headers the API actually accepts.

​
2026/02/04

Added the transfer.funds_refunded event in guides/webhooks/webhook-events. This event fires when funds are returned to the sender’s balance after a transfer fails (for example, an invalid payout destination or network delivery issue).
EventTriggerKey Payload Fields
transfer.funds_refundedFunds are refunded to the balance following a failed transfer.status: "funds_refunded", fees (array with refund-related fees), pay_out (original destination details), updated_at
Use this event to automatically reconcile balances, notify users that their funds have been returned, or trigger retry logic.
Introduced token sharing capability to enable seamless customer onboarding across platforms using Sumsub. Businesses can now import pre-verified KYC data from partner platforms, eliminating duplicate verification processes.Key details:
  • Endpoint: POST /v1/customers/{id}/token-share
  • Integration: Requires Sumsub account with Reusable KYC feature enabled
  • Supported: Individual customers only (not business customers)
New guide: guides/customers/token-sharing covers the complete flow from Sumsub token generation to importing verified customer data into Busha.This feature significantly reduces customer onboarding friction for businesses operating across multiple platforms.
  • Page: overview/transfers - Added funds_refunded to the list of possible transfer statuses so integrators know this terminal state exists.

​
January 2026

​
2026/01/30

  • Page: guides/getting-started/setup-sandbox
  • Updated the sandbox account registration link to point to the current developer console URL. - Refreshed the onboarding steps so new integrators land on the correct dashboard and can generate API keys without confusion.

​
2026/01/28

  • Page: guides/customers/transactions-on-behalf
  • Adjusted usage scenarios and parameter descriptions to stay accurate for delegated (on-behalf-of) transaction flows. - Ensured code samples reflect the latest required headers and request body shape.

​
2026/01/27

The following guides under guides/customers/ have been completely rewritten to improve clarity and align with current API behavior:
PageSummary of Changes
Create businessExpanded KYB (Know Your Business) workflow documentation, added field-by-field explanations for required business registration data, and included sample request/response payloads that match the live API.
Create individualOverhauled KYC (Know Your Customer) instructions with step-by-step guidance, clearer document-upload requirements, and updated example payloads reflecting actual field names and validation rules.
Verify identityClarified the verification lifecycle (from inactive → in_review → active or rejected), documented each possible status transition, and explained how to interpret verification outcomes programmatically.
Added comprehensive webhook coverage in guides/webhooks/webhook-events. The following four events are now documented with full sample payloads, trigger conditions, and recommended handling patterns:
EventTriggerKey Payload Fields
customer.verification.in_reviewCustomer submits verification documents and review begins.status: "in_review", level: "0", updated_at
customer.verification.activeReview succeeds; customer is fully verified.status: "active", level: "1", updated_at
customer.verification.rejectedReview fails due to invalid or incomplete documents.status: "rejected", rejection_reason, level: "0", updated_at
customer.verification.inactiveVerification reverted (compliance issue, suspension, etc.).status: "inactive", level: "0", updated_at
Each event follows the standard webhook envelope (business_id, event, data) and can be used to automate customer onboarding workflows, surface rejection reasons to end-users, or trigger compliance alerts.