Skip to main content

​
API Changelog

Stay informed about new features, improvements, and breaking changes to the 123hub API.
Subscribe to our developer newsletter to receive changelog updates via email.

​
2026

​
July 2026

​
v2.3.1 - Replay Header Compatibility

​
Replay headers remain optional
  • X-Data-Timestamp and X-Data-Nonce are an optional pair for every signed API method, including ticket, refund, chargeback, and attachment methods
  • Requests with neither replay header remain valid; sending only one header, a stale timestamp, or a reused nonce remains invalid
  • X-Data-Application-Id and the exact-body X-Data-Hash signature remain required and unchanged

​
v2.3.0 - Public Support API v1

​
Public Support API v1
  • Added strict signed API methods for merchant tickets, merchant-visible comments, and safe ticket attachments
  • Added idempotent full/partial refund.request with exact digit-string minor-unit amounts through signed PostgreSQL bigint max, public refund IDs, history, summaries, and comments
  • Added read-only chargeback history, summaries, evidence metadata, and short-lived authorized downloads
  • Added optional timestamp/nonce replay validation, API-key scopes, method quotas, cursor pagination, and stable numeric support errors
  • Added opt-in durable webhook events for ticket, refund, and chargeback changes; existing subscriptions and default scopes are unchanged
  • Rollout is controlled per resource and canary application; disabled methods remain unavailable without changing existing payment API behavior
  • Hardened attachment finalization and cleanup with bounded validation capacity, exact-size reads, fail-closed scanning, and opaque legacy evidence identifiers

​
v2.2.22 - Rich Deposit Receiver Instructions

​
Rich Deposit Receiver Instructions
  • payment.in responses can now return allowlisted P2P instructions in payment.receiver: bank name/code, receiver phone, document type/number, and QR payload
  • Provider-specific metadata is not exposed; Studio integrations must normalize provider fields into the documented bankDetails.* targets
  • Existing receiver.bank_account, payment.redirect and UPI deep-link contracts remain backward compatible

​
v2.2.21 - API Credential Usage Limits

​
API Credential Usage Limits
  • Successful signed API requests now update credential lifetime and UTC-day usage counters
  • Enforced credential daily limits return HTTP 429 with code 3009; rollout starts in observe mode so would-be rejections can be audited first
  • Developer Center reports daily usage separately from the lifetime request count

​
v2.2.20 - Catalogue-backed Payment Routes

​
Catalogue-backed Payment Routes
  • payment.in now accepts newly provisioned payment-method routes from the platform catalogue without requiring a gateway release for each method code
  • Malformed payment-method payloads return validation code 9000; unavailable or unconfigured methods return method-not-available code 1002 instead of a generic 1000
  • Method/configuration rejection happens before payment persistence, so invalid routes do not create failed payment records
  • Existing service_id request contracts and signatures are unchanged

​
v2.2.19 - Request Correlation

​
Request Correlation
  • The response body request_id now always matches the X-Request-ID response header
  • Payment creation logs link request_id to the returned payment h_id for operational investigations
  • Caller-provided X-Request-ID values remain diagnostic aliases and do not replace the server-generated identifier
  • No breaking API changes

​
v2.2.18 - Webhook Delivery Reliability

​
Webhook Delivery ReliabilityWebhook delivery and API error handling received reliability improvements.
  • Improved merchant callback retry behavior for temporary delivery and platform errors
  • payment.notification now queues callbacks for asynchronous delivery instead of waiting on merchant webhook endpoints
  • Webhook resend authentication errors now return the standard API error envelope instead of a generic server error
  • No breaking API changes

​
June 2026

​
v2.2.16 - Payment Creation Reliability

​
Payment Creation ReliabilityPayment creation and webhook delivery received reliability improvements for merchant integrations.
  • Increased the default payment creation timeout from 15s to 30s for payment.in and payment.out
  • Improved webhook callback delivery reliability and response handling
  • Improved payment request handling under slower provider responses
  • No breaking API changes

​
v2.2.15 - Removed legacy hosted payment pages

​
Removed legacy hosted payment-page endpointsThe legacy gateway-hosted payment-page surface has been removed. The platform routes all payments through external providers, so customer redirects are returned directly in the API response (payment.redirect) rather than via gateway-hosted pages.
  • Removed GET /payment-pages/:token, GET /payment-pages/:token/details, and the GET /payment-pages/:token/events SSE stream
  • These endpoints were no longer produced by any active payment flow; integrations should use the redirect URLs returned by payment.in/payment.out

​
v2.2.14 - Webhook Signature Binding

​
Webhook Signature BindingOutgoing webhooks now include a stronger replay-bound signature and safer resend behavior.
  • Added X-Webhook-Signature-V3, an HMAC-SHA512 signature over timestamp, nonce, delivery id, and raw body
  • Existing X-Webhook-Signature-V2 and X-Data-Hash headers remain available for backward-compatible verification
  • Manual payment notification resends now use a unique delivery id while keeping the public payload id stable
  • Hosted payment page generation now fails closed when signing or public URL configuration is missing

​
v2.2.13 - Studio Deposit Requisites

​
Studio Deposit RequisitesStudio-backed bank-transfer deposits can now return provider bank requisites in the payment creation response.
  • payment.in responses may include result.payment.receiver.bank_account when a Studio provider returns IBAN/account details
  • Existing redirect and UPI response formats are unchanged
  • No breaking API changes

​
v2.2.12 - Credential IP Enforcement

​
Credential IP EnforcementMerchant credentials with allowed_ips now enforce the configured exact IP/CIDR allowlist on 123hub API requests.
  • Requests outside the credential IP allowlist return API error 3006 with HTTP 400
  • Empty allowed_ips remains unrestricted for backward compatibility
  • Existing route policy behavior for allowed_currencies and allowed_service_ids is unchanged

​
v2.2.11 - Credential Route Policy

​
Credential Route PolicyMerchant production credentials can now be limited by currency and specific service_id routes for payment creation.
  • Added credential access policy for payment.in and payment.out
  • Empty policy remains unrestricted for backward compatibility
  • Policy failures return API error 3008 (CREDENTIAL_POLICY_DENIED) with HTTP 403
  • Webhook signing secret selection is unchanged

​
May 2026

​
v2.2.10 - Payout Limits & Webhook Delivery Reliability

​
Payout Limits & Webhook Delivery ReliabilityPayment and payout flows received reliability improvements and clearer limit guidance.
  • Clarified payment.out failure handling for insufficient balance (6004), monthly payout limits (6005), daily payout limits (6006), and other payout-limit rules such as since-last-settlement limits (6035)
  • Documented that daily and monthly payout limits reset in the merchant timezone
  • Improved webhook delivery recovery for events left in a retrying state
  • Added webhook delivery coverage for refunded payment lifecycle callbacks
  • Improved webhook delivery safety by requiring a signing secret before callback delivery
  • Improved balance read reliability for signed merchant integrations
  • No breaking API changes

​
v2.2.9 - Webhook Completion Timestamp Correction

​
Webhook Completion Timestamp CorrectionOutgoing payment and payout webhooks now report final success time from the confirmed provider completion timestamp.
  • data.result.payment.timestamps.finished now prefers confirmed_at for successful terminal payments
  • Success status history entries now use the same final provider confirmation time
  • processed_at remains the processing/initiation timestamp for async provider payouts

​
v2.2.8 - Legacy API-Key Surfaces Removed

​
Legacy API-Key Surfaces RemovedPublic merchant integrations now use signed signed API requests only.
  • Removed legacy X-API-Key authenticated /api/v1/balance and /api/v1/webhooks endpoints
  • Removed gateway websocket payment event broadcasts
  • Kept balance.get, payment.notification, outgoing signed webhooks, and signed webhook resend available through signed API authentication

​
v2.2.7 - Application Rate Limits

​
Application Rate LimitsValid merchant application keys now have high protective application-level ceilings for core public methods.
  • Added separate throttle buckets for payment.in, payment.out, payment.status, and balance.get
  • Keyed API throttles by merchant and application instead of client IP address
  • Configured payment creation buckets as abuse/runaway protection rather than normal operating limits
  • Throttled signed API requests now return HTTP 429 with the standard error envelope

​
v2.2.6 - Webhook Contract Drift Fixes

​
Webhook Contract Drift FixesPayment and payout webhook delivery now uses the same data.result.payment envelope for automatic callbacks, manual payment.notification re-sends, and template test webhooks.
  • payment.notification now resolves non-numeric h_id by exact payment lookup instead of fuzzy search
  • Manual notifications now preserve failed, expired, and refunded lifecycle payloads
  • Test webhook OpenAPI documentation now shows the current SHA-512 headers and callback envelope

​
v2.2.5 - Balance Endpoint Recovery

​
Balance Endpoint RecoveryMerchant balance reads were restored for API-key clients.
  • Added GET /balance for a merchant currency balance
  • Added GET /balance/all for all merchant balances
  • Documented both endpoints in the generated OpenAPI spec

​
April 2026

​
v2.2.4 - API Secret Webhook Signing

​
API Secret Webhook SigningOutgoing webhook signing now uses the merchant API secret for newly created or rotated webhook configurations.
  • Documented webhook verification as SHA512(rawBody + API secret)
  • Added api_secret, api_secret_version, and key_id to API secret rotation responses
  • Kept legacy secret, secret_key, and secret_version fields as deprecated compatibility aliases
  • Existing legacy webhook configurations continue to verify with their previously issued signing secret until API secret rotation

​
v2.2.3 - Public Contract Validation Sync

​
Public Contract Validation SyncPublic request validation and generated schema were reconciled.
  • Documented payment amounts as integer minor-unit values in the OpenAPI schema
  • Clarified per-payment webhook_url as an absolute public HTTP(S) URL with protocol
  • Added validation coverage for fractional payment amounts and protocol-less webhook URLs

​
v2.2.2 - Webhook Resend & Routing Reliability

​
Webhook Resend & Routing ReliabilityAdded merchant-facing recovery controls and improved payment routing reliability.
  • Added POST /payments/{paymentId}/webhook/resend to re-queue webhook delivery for a specific payment
  • Added a 10 requests/minute throttle to webhook resend requests
  • Improved deposit routing reliability with automatic provider fallback when cascade routing is enabled
  • Expanded accepted signed API request fields for payer, receiver, bank, redirect, identifiers, and per-payment webhook_url
  • Tightened per-payment webhook_url validation to require a valid public HTTP(S) URL
  • Fixed webhook consumer handling for queued delivery payloads
Breaking changes:
  • Per-payment webhook_url now must be a valid public HTTP(S) URL

​
v2.2.1 - Documentation Contract Sync

​
Documentation Contract SyncPublic documentation was reconciled with the current gateway contracts.
  • Added dedicated reference pages for API methods, outgoing webhooks, webhook management, and public payment pages
  • Corrected payment.status and payment.notification lookup identifiers to c_id and h_id; p_id is returned for reconciliation and is not a lookup key
  • Corrected Mexico payout examples: CLABE is sent in receiver.bank.account.id; receiver.bank.clabe is not accepted by the DTO
  • Reworked webhook payload docs to use data.result.payment, omit internal _payment_id, and document X-Data-Hash plus replay-protection headers
  • Documented actual webhook delivery defaults: timeout 30s, max_retries default 3, retry_delay_seconds default 1, jittered exponential retry with a 24h cap
  • Expanded the error code reference to cover every current PaymentApiErrorCode
  • Documented successful API response signing with X-Data-Hash

​
v2.2.0 - Turkey Direction & Payment Method Expansion

​
v2.2.0 — Turkey (TRY) Payment Direction & Documentation RefreshNew payment direction for Turkey and updated documentation to reflect actual system capabilities.New: Turkey (TRY) deposits:
  • Currency: TRY (Turkish Lira)
  • Payment methods: havale (bank transfer), papara (e-wallet), kredikarti (credit/debit card)
  • Deposits: havale (bank transfer), papara (e-wallet), kredikarti (credit/debit card)
  • Withdrawals: bank_transfer with IBAN
New: Additional currencies:
  • AUD (Australian Dollar) — deposit & withdrawal
  • LKR (Sri Lankan Rupee) — deposit & withdrawal
New payment methods documented:
  • upi — Unified Payments Interface (India, primary deposit method)
  • havale — Turkish bank transfer (Havale/EFT)
  • papara — Papara e-wallet (Turkey)
  • kredikarti — Turkish credit/debit card
  • imps — Immediate Payment Service (India)
New: payment.notification method documented:
  • Re-send webhook notification for a specific payment
Webhook documentation corrected:
  • Webhook payload now documents the delivered outer envelope (id, data, created_at, merchant_id) and keeps internal _payment_id out of merchant-facing examples
  • Documented fields absent in webhooks vs API (service_id, description, redirect, receiver.bank)
Response documentation expanded:
  • Added operations[] and operation fields to response reference
  • Added receiver.bank_account format for deposit responses (TRY, ARS)
  • Documented redirect.to type variations by region (array for UPI, string for Havale)
  • Clarified status.error type as integer | string | null
  • Noted h_id format varies by provider (numeric string or UUID)
  • Documented that receiver.bank is not returned in payment.status or webhooks
Documentation corrections:
  • Removed currencies with no active provider: BRL, CNY, COP, EUR, GEL, USD
  • Changed INR default method from bank_transfer to upi
  • Turkey (TRY) supports both deposits and withdrawals (not deposit-only)
  • Added region-specific bank fields: IFSC (India), CLABE (Mexico), bank code (Argentina), IBAN (Turkey)
Breaking changes:
  • None (additive only; removed currencies were never functional)

​
February 2026

​
v2.1.0 - Error Handling & Response Format Improvements

​
v2.1.0 — Error Handling, Balance, and Validation ImprovementsImproved API compatibility with the 123hub specification. Error handling, response formats, and validation have been updated.HTTP status codes (breaking change):
  • Error responses now return HTTP 400 (previously HTTP 200)
  • Unknown method errors (1002) return HTTP 404
  • Successful responses continue to return HTTP 200
  • Always check the success field to determine the outcome
Error response format:
  • error.details and error.context are now always present in error responses (value is null when not applicable)
  • Missing required field errors now use code 1005 with descriptive details object
  • Wrong hash/signature errors now return code 3000 (Authentication error)
  • next field removed from response envelope
New validation errors:
  • 6001 — Incorrect transaction amount (zero or negative)
  • 6002 — Incorrect currency code (mismatch with service_id)
  • 6009 — Payment already exists (duplicate c_id)
  • Missing payer object in payment.in now returns 1005 with specific description
gateway.ping format change (breaking change):
  • Response changed from "result": "pong" to "result": {"message": "pong"}
balance.get format change (breaking change):
  • Response restructured from result.balances[] to result.balance.{id, amounts[], enabled}
  • Balance fields renamed: available → value, frozen → value_freezing, added value_blocking and enabled
Redirect URLs:
  • Provider HTTPS payment page URLs are no longer included in redirect.to
  • Only UPI deep-link URLs (for India) are returned in redirect.to
Breaking changes:
  • HTTP status codes for errors changed from 200 to 400/404
  • next field removed from response envelope
  • gateway.ping response format changed
  • balance.get response structure completely changed
  • Error code for missing fields changed from 9000 to 1005
  • Error code for wrong hash changed from 3002 to 3000

​
January 2026

​
v2.0.0 - 123hub API Migration

​
v2.0.0 — 123hub API Migration (Breaking Change)Complete API redesign to 123hub.pro format. This is a breaking change — all integrations must be updated.New API format:
  • Single endpoint: POST /public/api/multihub/v1 replaces all previous REST endpoints
  • Method-based routing via body.method: payment.in, payment.out, payment.status, balance.get, gateway.ping
  • Standardized response envelope: { success, result, error, request_id, processing_time }
  • Success returns HTTP 200, errors return HTTP 400/404
New authentication:
  • X-Data-Application-Id (integer) + X-Data-Hash (SHA512) replaces X-API-Key
  • Webhook signatures changed from HMAC-SHA256 to SHA512 with X-Data-Hash header
New concepts:
  • service_id — integer mapping to provider + payment method combination
  • c_id / h_id / p_id — structured payment identifiers
  • Numeric error codes (1000-9000) replace HTTP status code-based errors
Removed:
  • REST endpoints (POST /api/v1/payments, GET /api/v1/balance, etc.)
  • X-API-Key authentication
  • P2P payment infrastructure (account-service, sms-service, qr-service)
  • Team management functionality
  • Device management functionality

​
v1.5.0 - In-Request Webhooks

​
Per-Payment Webhook URLYou can now pass a webhook URL directly in the payment creation request, enabling per-payment notification routing without pre-configuring webhooks.New Features
  • webhook_url: Optional field in POST /payments — specify a URL to receive webhook events for this specific payment
  • webhook_events: Optional array to choose which events to subscribe to (defaults to payment.created, payment.completed, payment.failed)
  • Automatic deduplication: If the same merchant sends the same webhook_url across multiple payments, the system reuses the existing webhook configuration
  • Webhook signing secret: In-request webhooks were originally signed with a per-merchant signing secret; current deliveries use the merchant API secret after API secret rotation
How it works
  • Pass webhook_url (and optionally webhook_events) when creating a payment
  • The system automatically creates (or reuses) a webhook endpoint for your merchant
  • Events are delivered to both admin-configured webhooks and in-request webhooks in parallel
  • In-request webhooks use SHA512 signature verification (updated in v2.0.0 from HMAC-SHA256)
API Changes
  • POST /payments now accepts optional webhook_url (string, max 2048 chars) and webhook_events (string array)
  • In-request webhooks are excluded from GET /webhooks listing by default (use ?source=in_request to view them)
  • Merchant detail response included the legacy default_webhook_secret field
Breaking changes
  • None (backwards compatible)

​
v1.4.0 - Webhook Security & Contract Stabilization

​
Webhook Payload WhitelistImproved security and API contract stability for webhook payloads.Changes
  • customer_data in webhook payloads now uses a whitelist approach — only specific, documented fields are included
  • Internal processing data (IP addresses, user agents, internal IDs, processing metadata) is no longer sent to merchant webhooks
  • payout object is now only included for withdrawal type payments (not for deposits)
Allowed customer_data fields
  • Top-level: note, customer_email, customer_phone, customer_name, external_id, reference, description, expires_at, requested_payment_type
  • commission: currency, total_minor
  • payout (withdrawals only): bank_code, bank_account, recipient_name, bank_name
Breaking changes
  • Webhook payloads no longer include internal fields that were previously exposed unintentionally
  • If your integration relied on undocumented fields in customer_data, you may need to update your webhook handler

​
2025

​
December 2025

​
v1.3.0 - Customer Management System

​
Customer Base & Payment LinkingNew customer management system that enables tracking and analytics across payments.New Features
  • Customer ID: Merchants can optionally pass customer_id when creating payments to link to an existing customer
  • Auto-linking: When customer_id is not provided, customers are automatically created/matched by email or phone
  • Customer Data in Response: Payment responses now include customer object with id, email, phone, name
API Changes
  • POST /payments now accepts optional customer_id field (integer)
  • Payment responses include customer_id and customer object
  • customer object in request body remains required (name, email, phone)
Breaking changes
  • None (backwards compatible)

​
v1.2.2 - Payment Page Enhancements

​
Standalone Payment Page & Return URL SupportMajor improvements to the hosted payment page experience.New Features
  • Return URLs: Merchants can now provide success_url and cancel_url for merchant settings for automatic redirect after payment completion
  • Mercado Pago Integration: Quick-pay button with deep link support (mobile devices only)
Technical Changes
  • Improved bundle size and performance
  • Fixed SSE event handling for real-time payment status updates
  • Payment page now correctly updates UI when payment status changes via SSE
API Changes
  • GET /payment-pages/:token/details now returns return_urls object with success_url and cancel_url
Breaking changes
  • None (backwards compatible)

​
v1.2.1 - API Consistency & Validation

​
API key format alignment and validation improvementsThis release fixes inconsistencies between API validation, documentation, and Swagger schemas.API Key Format Changes
  • Standardized API key format validation:
    • Test keys: qp_test_sk_* (e.g., qp_test_sk_abc123...)
    • Production keys: qp_prod_sk_* (e.g., qp_prod_sk_xyz789...)
  • Removed support for deprecated formats: qp_sandbox_sk_*, qp_live_*
  • Updated all documentation and Swagger examples to reflect correct key formats
Payment Status Updates
  • Added refunded and partial_refund statuses to payment API schemas
  • Payment pages now correctly display refund statuses
  • DTOs and filters now support filtering by refund statuses
Withdrawal Validation
  • recipient_name and bank_account are now required fields for withdrawal requests for ARS flow.
  • Improved error messages for missing payout details
  • Consistent validation across all withdrawal types
Documentation Fixes
  • Payment page URLs are now documented as dynamic (vary by currency/method/region)
  • Updated all code examples with correct API key formats
  • Clarified payout field requirements for different countries
Breaking changes
  • API keys using qp_sandbox_sk_* or qp_live_* formats will no longer be accepted
  • Withdrawal requests without recipient_name or bank_account will return 400 Bad Request

​
November 2025

​
v1.2.0 - Production Stability Release

​
Major improvementsFollowing the successful scaling deployment, we shipped a set of optimizations based on real world usage patterns.Improvements
  • Optimized payment processing pipeline for higher throughput
  • Increased rate limits for payment creation to 5000 requests per minute (burst: 500 requests per 10 seconds)
  • Improved webhook delivery reliability and retry mechanism
  • More descriptive error messages for validation failures
Performance
  • Reduced average API response time by about 40%
  • Faster payment status transitions
Breaking changes
  • None
​
Enhanced testing and quality of life
  • Improved consistency of API responses across endpoints
Breaking changes
  • None
​
Optimization and refactors
  • Internal architecture improvements for better scalability
  • Enhanced payment method validation rules
  • Improved balance calculation accuracy
Breaking changes
  • None

​
October 2025

​
v1.1.0 - Webhooks Improvements

​
Webhook manager improvementsNew features
  • Enhanced webhook signature binding for improved security and verification
Developer note
  • Make sure your webhook handlers are idempotent to safely handle retries.
Breaking changes
  • None
​
Webhook delivery fixes
  • Fixed webhook signature generation for consistent verification on client side
  • Improved webhook retry logic with exponential backoff
  • Enhanced request binding for webhook payloads
Breaking changes
  • None
​
Payment limits update
  • Corrected maximum amount validation rules
  • Improved amount formatting in API responses
Breaking changes
  • None
​
Production deployment optimizations
  • Enhanced API key handling and validation
  • Improved error responses for invalid credentials
  • Added support for additional payment method configurations
Breaking changes
  • None
Deprecation notice
  • API key formats qp_sandbox_sk_* and qp_live_* are deprecated and will stop working in December 2025
  • Please use the standard formats: qp_test_sk_* for test mode, qp_prod_sk_* for production

​
September 2025

​
v1.0.2 - Integration Fixes

​
Webhook flow corrections
  • Fixed payment.completed webhook not being sent in some scenarios
  • Improved webhook scheduling reliability
  • Enhanced stale webhook detection and cleanup
Breaking changes
  • None
​
Balance and withdrawal improvements
  • Resolved issues with balance calculations
  • Fixed withdrawal validation edge cases
  • Improved payment and requisite lock expiry handling
Breaking changes
  • None
​
API key and proxy compatibility
  • Fixed API key validation in specific edge cases
  • Improved proxy compatibility by handling X-Forwarded-Host headers
  • Strengthened request validation
Breaking changes
  • None
​
Documentation updates
  • Updated API documentation with corrected parameters
  • Removed redundant request parameters
  • Improved example payloads
Breaking changes
  • None

​
August 2025

​
v1.0.1 - Private Beta Improvements

​
Payment processing enhancements
  • Improved SPEI transfer handling
  • Enhanced bank account validation (CLABE format)
  • More informative error messages for invalid bank accounts
Breaking changes
  • None
​
Webhook reliability improvements
  • Added automatic retry for failed webhook deliveries
  • Implemented webhook event deduplication
  • Enhanced HMAC-SHA256 signature verification
Developer note
  • Webhook receivers should remain idempotent due to retries and deduplication.
Breaking changes
  • None
​
Balance API enhancements
  • Added /balance/all endpoint for multi-currency support
  • Improved balance precision handling
  • Added available and pending balance breakdown
Breaking changes
  • None

​
July 2025

​
v1.0.0 - Initial Release

​
Public API v1.0.0 releasePublic release of the 123hub Payment Gateway API.Core features
  • Payment creation (deposits and withdrawals)
  • Multiple payment methods support
  • Hosted payment pages (deposit_pp, withdrawal_pp)
  • Real time webhook notifications
  • Balance inquiry API
  • Test and production modes via API key prefixes (qp_test_sk_*, qp_prod_sk_*)
Supported payment methods
  • bank_transfer - bank transfers (Argentina, Uruguay)
  • spei - Mexican interbank transfers (SPEI)
  • oxxo - cash payments at OXXO stores
  • card - credit and debit cards (tokenized)
  • cash - cash payments
  • crypto - cryptocurrency payments
Supported currencies
  • ARS - Argentine peso
  • UYU - Uruguayan peso
  • MXN - Mexican peso
Webhook events
  • payment.created - payment initialized
  • payment.completed - payment successful
  • payment.failed - payment failed
  • payment.cancelled - payment cancelled
  • Withdrawals use the same payment.* events with destination: "out"
​
Private beta launch
  • Initial API endpoints for selected partners
  • Core payment functionality
  • Basic webhook support
  • Authentication via API keys

​
Versioning Policy

The 123hub API uses semantic versioning:
  • Major versions (v1, v2) indicate breaking changes
  • Minor versions add new features that are backwards compatible
  • Patches include bug fixes and minor improvements

​
Breaking changes

We strive to minimize breaking changes. When they occur:
  1. We announce them at least 1 month in advance
  2. We provide migration guides
  3. We support the previous version during a transition period

​
Deprecation policy

Deprecated features will:
  • Be announced in the changelog
  • Continue working for at least 3 months
  • Return deprecation warnings in API responses when possible

​
Migration Guides

When breaking changes occur, we will publish detailed migration guides here.

API Status

Check current API status and subscribe to incident updates.