Changelogs
All notable changes to the Bitnob API are documented here.
Send your first global payout
You can now accept and send USDC on Solana, enabling faster and more efficient transactions across your applications. With sub-second confirmation times and near-zero fees, this integration makes it easier to move funds instantly while reducing transaction costs, especially for high-frequency or cross-border use cases.
Payout webhooks now include FX breakdown
Webhook payloads for completed payouts now include detailed exchange rate and fee information, giving you better visibility into how each transaction is calculated. This makes it easier to reconcile payouts, track costs, and present accurate financial data within your systems.
Card Issuing API v2 beta
New card creation endpoints are now available, with support for physical cards, custom BIN ranges, and 3D Secure. This update provides greater flexibility in how you issue and manage cards, while also improving security and control over card transactions.
Fixed timeout on large batch payouts
Resolved an issue where batch payouts with 500+ recipients would intermittently time out. This fix improves reliability and ensures large-scale payouts are processed more consistently, reducing the need for retries or manual intervention.
Blockchain RPC: Optimism support
Added JSON-RPC and WebSocket endpoints for Optimism L2, including archive node access. This enables more efficient data querying, real-time updates, and deep historical insights for applications building on Optimism.
Virtual Cards API v2
Refactored the Virtual Cards API to a resource-oriented design. Replaced /api/virtualcards/* with /api/cards and /api/customers namespaces, standardized route structure using :cardId and :customerId path parameters, and consolidated card operations under /api/cards/:cardId/*. Added endpoints for extended card details, spending-limit controls, and customer-cards lookup.
Breaking changes: legacy Virtual Cards endpoints removed
All previous endpoints under /api/virtualcards are no longer supported. Card operations now require an explicit cardId path parameter instead of implicit context, and the user-based model has been replaced with a customer-centric model using customerId. Update integrations to the new /api/cards and /api/customers namespaces before upgrading.
| Old Endpoint | New Endpoint |
|---|---|
| POST /api/virtualcards/create | POST /api/cards |
| POST /api/virtualcards/topup | POST /api/cards/:cardId/fund |
| POST /api/virtualcards/withdraw | POST /api/cards/:cardId/withdraw |
| POST /api/virtualcards/freeze | POST /api/cards/:cardId/freeze |
| POST /api/virtualcards/unfreeze | POST /api/cards/:cardId/unfreeze |
| POST /api/virtualcards/terminate | POST /api/cards/:cardId/terminate |
Improved card and customer resource separation
Clear separation between card resources and customer resources, more intuitive and RESTful endpoint naming, and reduced endpoint duplication and ambiguity across the Virtual Cards surface.
Migration notes for Virtual Cards v2
Update all client integrations to use /api/cards endpoints, ensure cardId is passed explicitly for card-specific operations, replace card_user_id usage with customerId, and review permission and data models for compatibility with the new structure.