Technical specification

ZEONEBET Exchange feed specification

Version 1.0 · Updated 2026-09-20

Contract for machine-readable exchanger feeds. Adapter acceptance is reviewed per exchanger. Examples are illustrative — not every XML or JSON layout is plug-and-play.

Endpoint requirements

Protocol	HTTPS only (no http://, file://, or ftp://)
Encoding	UTF-8
Host	Stable public hostname — not localhost or private networks
Authorization	Host authorization occurs during technical review
Credentials	Do not put secrets in the public application; exchange them during onboarding

Required economic fields

Concepts ZEONEBET maps from each feed row:

Core feed concepts
FROM / TO asset	Source codes that identify each side of the pair
FROM amount (`in`)	Amount sent / given
TO amount (`out`)	Amount received
Min / max	Limits — document whether they refer to FROM amount
Reserve	Available TO-side amount where applicable

Optional fields (may not all be used today): updated timestamp, direction URL, fee metadata, manual-processing metadata, city/location metadata.

Rate semantics

RATE = TO units received per 1 FROM unit

Example: 1 USDT → 1.0008 USD means rate = 1.0008. Prefer explicit in/out amounts; partners need not precompute a rate when amounts are available.

Assets, networks, and payment rails

Network is part of canonical asset identity. USDT TRC20, USDT ERC20, USDT BEP20, and USDT TON must not all be sent as USDT unless accompanying fields unambiguously identify the network.

USD, Zelle USD, Wire USD, and Cash USD may be different ZEONEBET assets. Likewise INR, UPI INR, and Paytm INR. Provide explicit source codes and documentation — ZEONEBET does not infer them automatically.

Unknown source codes are rejected until reviewed and mapped by ZEONEBET.

Limits, reserves, and fees

Limits	Partners must document whether min and max refer to the FROM amount or another unit. ZEONEBET does not silently guess ambiguous units.
Reserve	Reserve should identify available TO-side amount where applicable. ZEONEBET does not aggregate reserves across assets.
Fees	ZEONEBET must not assume an undocumented fee field changes the customer's final receive amount.

Validation and XML safety

Rows with zero/negative amounts, unrecognized codes, or malformed structure may be rejected
XML feeds must be well-formed and bounded — no DTD, external entities, or XInclude
Prefer clear HTTP errors over HTTP 200 with HTML error pages

Update frequency, health, and failure

Update schedule	ZEONEBET currently checks approved feeds on a periodic schedule, typically around five minutes. This is not a contractual SLA.
Unavailable / invalid feed	If a feed becomes unavailable or invalid, ZEONEBET may temporarily exclude its offers from the public market while preserving last known internal data.
Zero valid rows	A feed returning zero accepted offers may be treated as failed rather than as an instruction to remove all current offers.

Notify ZEONEBET before materially changing feed schema or code meanings. Use the listing application for technical contact — no dedicated public partner email is published.

Illustrative examples

XML sample (example data only)

<rates>
  <item>
    <from>USDTTRC20</from>
    <to>ZELLEUSD</to>
    <in>1000</in>
    <out>1000.80</out>
    <minamount>100</minamount>
    <maxamount>5000</maxamount>
    <amount>15000</amount>
  </item>
</rates>

JSON sample (illustrative semantics)

{
  "offers": [
    {
      "from": "USDTTRC20",
      "to": "ZELLEUSD",
      "in": "1000",
      "out": "1000.80",
      "minFrom": "100",
      "maxFrom": "5000",
      "reserveTo": "15000"
    }
  ]
}

Illustrative only. Arbitrary JSON is not automatically supported. Actual integration is reviewed per exchanger.

Apply to list your exchanger Listing overview