Skip to main content
This section describes the operational behavior and lifecycle assumptions partners should consider when integrating with the Nexbridge Partner API.

​
Approved Addresses Only

Only approved (whitelisted) addresses may participate in platform operations involving supported assets. Depending on the business flow, an address may be used as the source of deposited funds or as the destination for asset delivery. Requests referencing:
  • pending addresses
  • inactive addresses
  • unsupported addresses
are rejected operationally.

​
Single Active USDT Address

Only one active USDT payout address is supported at a time (redemption). This restriction applies to automated payout operations. Partners should avoid deleting active addresses before replacement approval is completed.

​
Quote Expiration

Quotes are time-limited. Expired quotes:
  • cannot create requests
  • cannot be reactivated
  • cannot be reused
Partners should create requests immediately after obtaining a quote.

​
Single Quote Usage

Quotes may only be consumed once. A consumed quote cannot be reused for additional requests.

​
Partial Funding

Requests support partial funding. As a result:
  • multiple funding events may fund one request
  • one funding event may contribute to multiple requests

​
Funding Validation

Funding must:
  • match the expected asset
  • originate from approved sources
  • satisfy operational validation rules
Funding failing validation transitions to:
Funding classified as Dirty cannot participate in settlement or order fulfillment. It is segregated from eligible balances and requires manual review and operational intervention by the NexBridge team before any further action can be taken.

​
Asynchronous Settlement

Request processing and settlement are asynchronous. Request fulfillment timing may vary depending on:
  • funding timing
  • operational validation
  • settlement lifecycle
Partners should monitor request status continuously.

​
Request Cancellation

Requests may only be cancelled while still operationally pending. Completed or fulfilled requests cannot be cancelled.

​
Balance Lifecycle

Balances evolve dynamically depending on:
  • funding reception
  • allocation
  • settlement completion
  • request lifecycle
Balances may transition between:
  • available
  • allocated
  • dirty
  • consumed

​
Precision Rules

​
USTBL

Supports up to 6 decimals.

​
USDT

Supports up to 2 decimals.

​
Operational Traceability

All operational lifecycle transitions are internally traced for:
  • requests
  • funding activity
  • balance movements
  • settlement operations

​
Idempotency Recommendation

Partners should implement idempotent request handling on their side. This helps prevent duplicated operational requests caused by:
  • retries
  • network failures
  • timeout scenarios

​
Best Practices

Partners are encouraged to:
  • monitor request statuses continuously
  • avoid reusing expired quotes
  • validate operational addresses before usage
  • rotate payout addresses carefully
  • implement retry and reconciliation logic