POST /apiv2/screening

کسی بلاک چین ایڈریس کے لیے AML اسکریننگ کا آرڈر دیں۔ یہ ورژن 2 کا معاہدہ ہے: ہر فراہم کنندہ (provider) اور آرڈر کی ہر حالت کے لیے ایک ہی جواب کی ساخت، اعشاری نمبر بطور اسٹرنگز، اور ایک واحد نقص کی فارمیٹ۔

یہ POST /apiv2/aml کی جگہ لیتا ہے، جو بدستور کام کر رہا ہے اور بغیر اطلاع کے ختم نہیں کیا جا رہا ہے۔

Endpoint کا URL

POST https://netts.io/apiv2/screening

درخواست کے Headers

ہیڈر	لازمی	تفصیل
Content-Type	ہاں	application/json
X-API-KEY	ہاں	Netts ڈیش بورڈ سے آپ کی API کی
X-Idempotency-Key	نہیں	محفوظ دوبارہ کوششوں کے لیے آپ کی اپنی کی (key)۔ دیکھیں Idempotency

درخواست کا Body

json

{
    "address": "YOUR_ADDRESS_HERE",
    "network": "trx",
    "provider": "elliptic",
    "wait_for_result": true
}

پیرامیٹرز

پیرامیٹر	قسم	لازمی	تفصیل
address	اسٹرنگ	ہاں	اسکرین کرنے کے لیے ایڈریس، 10–128 کریکٹرز
network	اسٹرنگ	ہاں	نیٹ ورک ٹکر۔ ہر فراہم کنندہ جن ٹکرز کا احاطہ کرتا ہے وہ GET /apiv2/screening/providers کے ذریعے درج ہیں؛ نیٹ ورکس کے ناموں کے ساتھ مکمل جدول یہاں ہے
provider	اسٹرنگ	ہاں	`elliptic` یا `bitok`۔ کوئی ڈیفالٹ نہیں ہے
wait_for_result	بولین	نہیں	`true` زیادہ سے زیادہ 15 سیکنڈ تک نتیجے کا انتظار کرتا ہے۔ ڈیفالٹ `false`
language	اسٹرنگ	نہیں	رپورٹ کی زبان۔ صرف `en`

نامعلوم فیلڈز کو مسترد کر دیا جاتا ہے۔ اوپر دیے گئے جدول میں غیر موجود فیلڈ پر مشتمل باڈی کوڈ 4001 کے ساتھ 400 لوٹاتی ہے۔ ورژن 1 میں نامعلوم فیلڈز کو خاموشی سے نظر انداز کر دیا جاتا تھا، اور wait کی غلط املا کا مطلب یہ تھا کہ کال کرنے والے نے ایسے نتیجے کا انتظار کیا جو کبھی بھی بیک وقت موصول نہیں ہونا تھا۔

provider لازمی ہے اور اس کا کوئی ڈیفالٹ نہیں ہے۔ ورژن 1 میں کسی فراہم کنندہ کو چھوڑ دینے کا مطلب Elliptic تھا، لہذا جس کال کرنے والے نے انتخاب نہیں کیا اس نے ایسے فراہم کنندہ کے لیے ادائیگی کی جس کا اس نے کبھی نام نہیں لیا تھا۔

provider سکیما میں ایک آزادانہ اسٹرنگ ہے، کوئی enumeration نہیں۔ آج دو اقدار قبول کی جاتی ہیں؛ تیسرا فراہم کنندہ کسی بھی ایسے شخص کے لیے بریکنگ چینج نہیں ہونا چاہیے جو سکیما کے مطابق جوابات کی توثیق کرتا ہے۔ موجودہ فہرست، وہ نیٹ ورکس جن کا ہر فراہم کنندہ احاطہ کرتا ہے اور وہ پیمانہ جس پر ہر ایک اسکور کرتا ہے، GET /apiv2/screening/providers سے حاصل ہوتے ہیں۔

نمونہ درخواستیں

cURL — نتیجے کا انتظار کریں

bash

curl -X POST https://netts.io/apiv2/screening \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: your_api_key" \
  -d '{
    "address": "YOUR_ADDRESS_HERE",
    "network": "trx",
    "provider": "elliptic",
    "wait_for_result": true
  }'

cURL — قبول کریں اور پول (poll) کریں

bash

curl -X POST https://netts.io/apiv2/screening \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: your_api_key" \
  -d '{
    "address": "YOUR_ADDRESS_HERE",
    "network": "trx",
    "provider": "bitok"
  }'

جواب Location ہیڈر کے ساتھ 202 Accepted ہوتا ہے جو آرڈر کی طرف اشارہ کرتا ہے۔

Python

python

import requests
from decimal import Decimal

url = "https://netts.io/apiv2/screening"
headers = {
    "Content-Type": "application/json",
    "X-API-KEY": "your_api_key",
}
payload = {
    "address": "YOUR_ADDRESS_HERE",
    "network": "trx",
    "provider": "elliptic",
    "wait_for_result": True,
}

response = requests.post(url, headers=headers, json=payload)

if response.status_code in (200, 202):
    body = response.json()
    print("Order:", body["order"]["client_order_id"])
    print("Status:", body["order"]["status"])
    if body["risk"]["score"] is not None:
        # Parse provider numbers as Decimal, never as float
        print("Score:", Decimal(body["risk"]["score"]), "of", body["risk"]["scale"]["max"])
    print("Level:", body["risk"]["level"], "-", body["risk"]["level_source"])
    print("Charged:", body["billing"]["charged_amount"], body["billing"]["charged_currency"])
else:
    problem = response.json()
    print(problem["code"], problem["title"], "-", problem["detail"])

جواب کے کوڈز

صورتحال	کوڈ	ہیڈرز
آرڈر بن گیا، اسکریننگ پس منظر میں چل رہی ہے	`202 Accepted`	`Location: /apiv2/screening/{client_order_id}`
نتیجہ جواب میں موجود ہے (`wait_for_result`)	`200 OK`	—
نتیجہ حالیہ چیک سے دوبارہ استعمال کیا گیا، کوئی کٹوتی نہیں ہوئی	`200 OK`	—
ایڈریس کی کوئی بلاک چین سرگرمی نہیں ہے، کوئی کٹوتی نہیں ہوئی	`200 OK`	—
نقص	دیکھیں Errors	`Content-Type: application/problem+json`

اسکریننگ کا نتیجہ لے جانے والے جوابات Cache-Control: private, no-store کے ساتھ بھیجے جاتے ہیں۔

جواب

json

{
  "schema_version": 2,
  "order": {
    "client_order_id": "A90D21F68C9AEA2",
    "status": "completed",
    "api_version": "v2",
    "cache_hit": false,
    "created_at": "2026-09-13T08:14:29.614988Z",
    "started_at": "2026-09-13T08:14:30.288251Z",
    "completed_at": "2026-09-13T08:14:34.993174Z"
  },
  "request": {
    "address": "YOUR_ADDRESS_HERE",
    "network": "trx",
    "provider": "elliptic"
  },
  "billing": {
    "charged": true,
    "price_usdt": "0.98",
    "base_amount": "2.882421",
    "markup_amount": "0",
    "charged_amount": "2.882421",
    "charged_currency": "TRX",
    "exchange_rate": "0.33999200",
    "payment_status": "pending"
  },
  "precheck": {
    "activity_checked": true,
    "activity_status": "active",
    "source": "tron-address-checker"
  },
  "check": {
    "provider": "elliptic",
    "provider_check_id": "b4903a5d-9f22-4075-b51b-beb40b419b97",
    "checked_at": "2026-09-13T08:14:32.144000Z",
    "status": "completed",
    "provider_status": "complete"
  },
  "risk": {
    "score": "0.9634087310611608",
    "scale": { "min": 0, "max": 10 },
    "level": "low",
    "level_source": "computed",
    "provider_level": null,
    "policy": "netts-risk-v1",
    "by_direction": {
      "source": "0.12332156899576921",
      "destination": "0.9634087310611608"
    }
  },
  "sanctions": {
    "self": false,
    "self_entities": null,
    "exposure": {
      "entity": "HTX (formerly Huobi) - Post-Sanctions - UK Sanctions List - 26 May 2026",
      "category": "Exchange",
      "share_fraction": "0.004409451392423414",
      "proximity": "indirect",
      "hops": 3,
      "direction": "source",
      "rule_name": "Sanctioned, TF & CSAM"
    },
    "items": []
  },
  "exposure": [
    {
      "category": "Exchange",
      "share_fraction": "0.1888065152442461",
      "direction": "source",
      "hops": 2,
      "is_screened_address": false,
      "entities": [
        { "name": "Binance", "category": "Exchange", "is_vasp": true,
          "is_primary": true, "is_after_sanction_date": null }
      ]
    }
  ],
  "rules": [
    { "name": "Sanctioned, TF & CSAM", "type": "exposure", "level": null,
      "score": "0.061426483114820525", "share_fraction": null, "category": null,
      "proximity": null, "direction": "source", "detected_at": null }
  ],
  "entities": [
    { "name": "Unknown", "category": "Unknown", "is_vasp": null,
      "is_primary": true, "is_after_sanction_date": false }
  ],
  "primary_entity": {
    "name": "Unknown", "category": "Unknown", "is_vasp": null,
    "is_primary": true, "is_after_sanction_date": false
  },
  "sanctioned_entities": [],
  "wallet": {
    "inflow_usd": "354663.6116669158",
    "outflow_usd": "80248.63081808022"
  },
  "provider_data": { }
}

فیلڈز کا سیٹ کبھی تبدیل نہیں ہوتا

اوپر درج ہر بلاک ہر جواب میں موجود ہوتا ہے، چاہے کوئی بھی فراہم کنندہ ہو اور آرڈر کی حالت کچھ بھی ہو۔ جو چیز کوئی فراہم کنندہ فراہم نہیں کرتا وہ null ہوتی ہے؛ ایک فہرست جس میں کچھ بھی نہیں ہے وہ [] ہوتی ہے، نہ کہ null؛ ایک بلاک جس میں ابھی تک کوئی ڈیٹا نہیں ہے اسے خارج کرنے کے بجائے nulls سے بھر دیا جاتا ہے۔ ایک ہی پارسر اس چیک کو سنبھالتا ہے جسے ابھی قبول کیا گیا ہو اور اسی چیک کو اس وقت بھی جب وہ مکمل ہو چکا ہو۔

آپ کے کوڈ کے لیے دو نتائج:

ان فیلڈز کو نظر انداز کریں جنہیں آپ نہیں جانتے۔ بغیر کسی نئے ورژن کے ان بلاکس میں نئی فیلڈز شامل کی جاتی ہیں۔ کسی نامعلوم فیلڈ کو مسترد کرنا آپ کا نقص (bug) ہے، ہمارا نہیں۔
provider_data معاہدے کا حصہ نہیں ہے۔ اس کی ساخت فراہم کنندہ کے مطابق ہوتی ہے، اور جب فراہم کنندہ تبدیل ہوتا ہے تو یہ تبدیل ہو جاتی ہے۔ معاہدہ جس چیز کی بھی ضمانت دیتا ہے وہ اوپر دیے گئے بلاکس میں موجود ہے۔

`order`

فیلڈ	قسم	تفصیل
client_order_id	اسٹرنگ	آرڈر کا شناختی کوڈ، بعد میں نتیجہ پڑھنے کے لیے استعمال ہوتا ہے
status	اسٹرنگ	`pending`، `processing`، `completed`، `skipped`، `failed`
api_version	اسٹرنگ	وہ معاہدہ جس نے آرڈر بنایا
cache_hit	بولین	`true` جب حالیہ نتیجہ دوبارہ استعمال کیا گیا ہو اور کوئی کٹوتی نہ ہوئی ہو
created_at	اسٹرنگ	RFC 3339، UTC، مائیکرو سیکنڈز
started_at	اسٹرنگ \| null	فراہم کنندہ کی کال کب شروع ہوئی۔ `skipped` کے لیے `null`
completed_at	اسٹرنگ \| null	نتیجہ کب موصول ہوا
error	اسٹرنگ	صرف `failed` کے لیے: یہ کیوں ناکام ہوا
reason	اسٹرنگ	صرف `skipped` کے لیے: `address_inactive`

تمام ٹائم اسٹیمپ UTC، RFC 3339، ایک Z لاحقے اور مائیکرو سیکنڈ کی درستگی کے ساتھ ہیں۔

`billing`

فیلڈ	قسم	تفصیل
charged	بولین	آیا رقم لی گئی ہے
price_usdt	اسٹرنگ	USDT میں فراہم کنندہ کی لسٹ پرائس
base_amount	اسٹرنگ	چارج کی گئی کرنسی میں آرڈر کی قیمت، ذیلی صارف کے مارک اپ کے بغیر
markup_amount	اسٹرنگ	ذیلی صارف کا مارک اپ۔ براہ راست اکاؤنٹ کے لیے `"0"`
charged_amount	اسٹرنگ	بیلنس سے اصل میں کیا لیا گیا
charged_currency	اسٹرنگ	`TRX`
exchange_rate	اسٹرنگ \| null	تبادلے کے لیے استعمال ہونے والی شرح
payment_status	اسٹرنگ	`paid`، `pending`، `failed`، `not_charged`

کامیاب چیک کے بعد مختصر وقت کے لیے payment_status کی قدر pending ہوتی ہے: رقم پہلے روکی جاتی ہے اور ایک گھنٹے کے اندر طے پاتی ہے۔ failed کا مطلب ہے کہ رقم واپس کر دی گئی۔ not_charged کا مطلب ہے کہ کبھی کوئی کٹوتی بنائی ہی نہیں گئی — دوبارہ استعمال شدہ نتیجہ یا چھوڑا گیا ایڈریس۔

`precheck`

ادائیگی والی اسکریننگ سے پہلے ایڈریس کی بلاک چین سرگرمی کے لیے جانچ کی جاتی ہے۔ بغیر کسی سرگرمی والے ایڈریس کو فراہم کنندہ کو نہیں بھیجا جاتا اور نہ ہی کوئی کٹوتی کی جاتی ہے۔

فیلڈ	قسم	تفصیل
activity_checked	بولین	آیا جانچ کی گئی۔ ان نیٹ ورکس پر `false` جہاں یہ موجود نہیں ہے
activity_status	اسٹرنگ	`active`، `inactive`، `unknown`
source	اسٹرنگ \| null	میکانزم کا نام

unknown بامعاوضہ اسکریننگ کو نہیں روکتا: اگر ایکٹیویٹی سروس دستیاب نہ ہو تو ایڈریس کو فعال سمجھا جاتا ہے۔

`check`

فیلڈ	قسم	تفصیل
provider	اسٹرنگ	جانچ کرنے والا فراہم کنندہ
provider_check_id	اسٹرنگ \| null	فراہم کنندہ کا اپنا شناختی کوڈ — ان کے ساتھ کسی نتیجے پر تنازع کرتے وقت اس کا حوالہ دیں
checked_at	اسٹرنگ \| null	فراہم کنندہ نے نتیجہ کب تیار کیا
status	اسٹرنگ	نیچے دیا گیا جدول دیکھیں
provider_status	اسٹرنگ \| null	فراہم کنندہ کے اپنے الفاظ، غیر تبدیل شدہ

`order.status`	`check.status`	مفہوم
`pending`	`pending`	آرڈر قبول کر لیا گیا، ابھی شروع نہیں ہوا
`processing`	`running`	فراہم کنندہ اس پر کام کر رہا ہے
`completed`	`completed`	نتیجہ موصول ہو گیا
`failed`	`failed`	فراہم کنندہ کی کال سے پہلے یا اس کے دوران مسترد کر دیا گیا
`skipped`	`not_performed`	ایڈریس کی کوئی سرگرمی نہیں ہے؛ فراہم کنندہ کو کبھی کال نہیں کیا گیا اور کوئی کٹوتی نہیں ہوئی

`risk`

فیلڈ	قسم	تفصیل
score	اسٹرنگ \| null	فراہم کنندہ کا اپنا اسکور، بطور اعشاری اسٹرنگ
scale	آبجیکٹ	اس فراہم کنندہ کے پیمانے کا `min` اور `max`
level	اسٹرنگ	`none`، `low`، `medium`، `high`، `severe`
level_source	اسٹرنگ	`computed` — ہم نے اسکور سے سطح اخذ کی؛ `provider` — فراہم کنندہ نے اسے بیان کیا
provider_level	اسٹرنگ \| null	فراہم کنندہ کا اپنا لفظ، جب وہ کوئی فراہم کرے
policy	اسٹرنگ	حد بندی پالیسی کا نام، `netts-risk-v1`
by_direction	آبجیکٹ	اسکور کو `source` اور `destination` میں تقسیم کیا گیا ہے، جب فراہم کنندہ اسے تقسیم کرتا ہے

اسکور کو کبھی دوبارہ ناپا (rescale) نہیں جاتا۔ Elliptic کا پیمانہ 0–10 اور BitOK کا 0–1 ہے، اور ایک پیمانے پر 7 کا مطلب کسی بھی لحاظ سے دوسرے پر 0.7 نہیں ہے۔ پیمانہ جواب میں آتا ہے تاکہ ایک فراہم کنندہ کے لیے لکھی گئی انٹیگریشن ایک ہی کنفیگریشن تبدیلی کے بعد دوسرے کو غلط نہ سمجھ لے۔

لیول پوری API میں ایک واحد اصطلاح ہے۔ جہاں فراہم کنندہ اپنی ایک سطح بتاتا ہے ہم اسے آگے منتقل کرتے ہیں اور level_source میں ایسا کہہ دیتے ہیں؛ جہاں وہ نہیں بتاتا، ہم netts-risk-v1 کی حدود کے ساتھ اسکور سے سطح اخذ کرتے ہیں اور اس کے بجائے وہ کہہ دیتے ہیں۔ ایک ہی چیک کے لیے API جواب، ڈیش بورڈ اور PDF رپورٹ میں ایک ہی لفظ ظاہر ہوتا ہے۔

`exposure[]`، `rules[]`، `entities[]`

exposure[] فنڈز کو فریق ثانی (counterparty) کے زمرے کے لحاظ سے تقسیم کرتا ہے۔ rules[] فراہم کنندہ کے ان قواعد کی فہرست دیتا ہے جو متحرک ہوئے۔ entities[] ان اداروں کی فہرست دیتا ہے جن سے ایڈریس خود تعلق رکھتا ہے؛ primary_entity ایک مقررہ قاعدے کے تحت ان میں سے ایک کا انتخاب کرتا ہے — وہ ادارہ جسے فراہم کنندہ نے بنیادی کے طور پر نشان زد کیا، ورنہ پہلا، بصورت دیگر null۔ sanctioned_entities[] میں entities[] کے وہ ادارے شامل ہیں جنہیں پابندیوں کی تاریخ کے بعد فعال کے طور پر نشان زد کیا گیا ہے۔

شیئرز کسر (fractions) ہیں، کبھی فیصد نہیں

جواب میں ہر شیئر ایک واحد فیلڈ، share_fraction ہے، جو "0" اور "1" کے درمیان ایک اعشاری اسٹرنگ ہے۔

text

Elliptic reports 31.574732212596924 %  ->  "share_fraction": "0.31574732212596924"
BitOK reports    0.8488                ->  "share_fraction": "0.8488"

فراہم کنندگان اکائیوں پر متفق نہیں ہیں: نمائش کا وہی ایک تہائی حصہ ایک سے 31.57 کے طور پر اور دوسرے سے 0.3157 کے طور پر آتا ہے۔ فراہم کنندہ کو جانے بغیر دونوں کو لے جانے والی ایک ہی فیلڈ کو پڑھنا ناممکن ہوگا۔ فراہم کنندہ کا اپنا نمبر فراہم کنندہ کی اپنی اکائیوں میں provider_data میں رہتا ہے۔

اعداد اسٹرنگز ہیں

فراہم کنندہ سے آنے والا ہر نمبر — اسکورز، شیئرز، USD والیومز، اور billing میں ہر رقم — ایک اعشاری اسٹرنگ ہے۔

json

"score": "0.9634087310611608"

JavaScript، Go یا بائنری فلوٹنگ پوائنٹ والی کسی دوسری زبان میں اسے JSON نمبر کے طور پر پارس کرنا ایک تخمینی قدر دیتا ہے، اور جو قدر آپ پرنٹ کرتے ہیں وہ فراہم کنندہ کی جاری کردہ قدر سے مطابقت رکھنا بند کر دیتی ہے۔ ان فیلڈز کو اعشاری قسم کے ساتھ پارس کریں: Python میں Decimal، Java میں BigDecimal، JavaScript میں decimal.Decimal یا اسٹرنگ۔

وہ فیلڈز جو فراہم کنندہ کے بجائے ہماری ہیں — scale.min، scale.max، hops — سادہ JSON اعداد ہیں۔

حالیہ نتیجے کا دوبارہ استعمال

جب آپ 60 سیکنڈ کے اندر اسی ایڈریس، نیٹ ورک اور فراہم کنندہ کو دوبارہ اسکرین کرتے ہیں، تو پہلے والا نتیجہ واپس کر دیا جاتا ہے اور کوئی کٹوتی نہیں کی جاتی۔

ہر درخواست اب بھی اپنے client_order_id کے ساتھ اپنا آرڈر بناتی ہے؛ دوبارہ استعمال ہونے والے آرڈر پر "cache_hit": true نشان زد ہوتا ہے اور اس کا billing بلاک "payment_status": "not_charged" کے ساتھ "charged": false رپورٹ کرتا ہے۔ جس آرڈر سے نتیجہ آیا ہے اس کا شناختی کوڈ ظاہر نہیں کیا جاتا — ہو سکتا ہے کہ وہ کسی دوسرے اکاؤنٹ کا ہو۔

دوبارہ استعمال صرف ایک اکاؤنٹ کے اندر ہوتا ہے۔ کسی اور کی طرف سے اسکرین کیا گیا نتیجہ کبھی آپ کو واپس نہیں کیا جاتا۔

Idempotency

دوبارہ کوشش کو محفوظ بنانے کے لیے اپنی ایک ویلیو کے ساتھ X-Idempotency-Key بھیجیں: اسی باڈی کے ساتھ وہی کی (key) دوسری جانچ کا آرڈر دینے کے بجائے محفوظ شدہ جواب لوٹاتی ہے۔

صورتحال	کوڈ	جواب
اس کی (key) کے ساتھ پہلی درخواست اب بھی چل رہی ہے	`409`	`4090`
وہی کی، ایک مختلف درخواست باڈی	`409`	`4093`
وہی کی، وہی باڈی، پہلے ہی مکمل ہو چکی ہے	محفوظ شدہ کوڈ	محفوظ شدہ جواب

اگر آپ ہیڈر نہیں بھیجتے ہیں، تو دو سیکنڈ کی ونڈو میں API کی، ایڈریس، فراہم کنندہ اور آپ کے IP ایڈریس سے آپ کے لیے ایک کی تیار کی جاتی ہے۔ یہ ڈبل کلک اور گیٹ وے کی دوبارہ کوشش سے حفاظت کرتی ہے، ایک منٹ بعد دوبارہ کوشش سے نہیں: وہ ایک حقیقی نیا آرڈر ہوتا ہے اور اس کی کٹوتی کی جاتی ہے۔

کیز کا دائرہ کار فی اینڈ پوائنٹ ہوتا ہے۔ POST /apiv2/aml اور اس اینڈ پوائنٹ پر بھیجی گئی ایک ہی ویلیو دو مختلف درخواستوں کے بارے میں دو آزاد وعدے ہیں — باڈیز مختلف ہیں، اور جوابات بھی مختلف ہیں۔ کسی انٹیگریشن کو ورژن 1 سے ورژن 2 پر منتقل کرتے وقت اپنی کی کا دوبارہ استعمال محفوظ ہے: یہ نہ تو آپ کو ورژن 1 کا جواب لوٹاتی ہے اور نہ ہی مختلف باڈی کے ساتھ استعمال ہونے والی ایک ہی کی کے طور پر شمار ہوتی ہے۔

نقائص

ایپلیکیشن کی طرف سے پیدا ہونے والا ہر نقص Content-Type: application/problem+json کے ساتھ RFC 9457 استعمال کرتا ہے:

json

{
  "type": "https://doc.netts.io/api/v2/errors/insufficient-funds",
  "title": "Insufficient funds",
  "status": 403,
  "detail": "Insufficient funds. Required: 2.888742 TRX, Available: 1.203000 TRX",
  "instance": "/apiv2/screening",
  "code": 1004,
  "required_trx": "2.888742",
  "available_trx": "1.203000"
}

type، title، status، detail اور instance معیاری فیلڈز ہیں۔ عددی code کو ایک توسیعی فیلڈ کے طور پر رکھا گیا ہے تاکہ ورژن 1 کے لیے لکھی گئی انٹیگریشنز اس پر مطابقت برقرار رکھ سکیں۔ اضافی فیلڈز کا انحصار نقص پر ہوتا ہے اور جب آپ انہیں نہ جانتے ہوں تو انہیں نظر انداز کر دینا چاہیے۔

کوڈ	HTTP	مفہوم
`4000`	400	باڈی درست JSON نہیں ہے
`4001`	400	ایک فیلڈ کی توثیق ناکام ہو گئی، یا کوئی نامعلوم فیلڈ بھیجی گئی تھی
`4002`	403	فراہم کنندہ آپ کے اکاؤنٹ کے لیے دستیاب نہیں ہے
`4003`	400	ناقص آرڈر شناختی کوڈ
`4004`	400	فراہم کنندہ درخواست کردہ نیٹ ورک کو سپورٹ نہیں کرتا
`4010`	401	کوئی API کی موجود نہیں ہے
`4011`	401	API کی یا IP ایڈریس قبول نہیں کیا گیا
`4040`	404	آرڈر نہیں ملا
`4041`	404	اکاؤنٹ نہیں ملا
`4090`	409	اس idempotency کی کے ساتھ ایک درخواست اب بھی چل رہی ہے
`4091`	409	ڈپلیکیٹ درخواست
`4093`	409	یہ idempotency کی ایک مختلف باڈی کے ساتھ استعمال کی گئی تھی
`1004`	403	ناکافی بیلنس
`5000`	500	اندرونی نقص
`5001`	500	رقم کی کٹوتی مکمل نہیں ہو سکی
`5002`	500	آرڈر نہیں بنایا جا سکا
`5030`	503	فراہم کنندہ دستیاب نہیں ہے

وہ نقائص جو اس فارمیٹ کو استعمال نہیں کرتے

کچھ ناکامیاں گیٹ وے پر ہوتی ہیں، ایپلیکیشن تک پہنچنے سے پہلے، اور وہ گیٹ وے کی اپنی ہی ساخت برقرار رکھتی ہیں۔ کسی بھی ایسے جواب کو جس کا Content-Type، application/problem+json نہ ہو، ان میں سے ایک سمجھیں:

صورتحال	HTTP	باڈی
کوئی API کی نہیں ہے، یا ایسی کی جو قبول نہیں کی گئی	401	`{"detail":{"code":-1,"msg":"Invalid or missing API key"}}`
شرح کی حد (rate limit) سے تجاوز کر گیا	429	`{"message":"API rate limit exceeded"}`
نامعلوم راستہ، یا ایسا طریقہ (method) جو روٹ پر فراہم نہیں کیا جاتا	404 / 405	`{"detail":"Method Not Allowed"}`

Rate Limits

یہ حد POST /apiv2/aml اور دیگر AML راستوں کے ساتھ مشترک ہے: 5 درخواستیں فی سیکنڈ اور 150 فی منٹ۔ اس اینڈ پوائنٹ پر منتقل ہونے سے آپ کو اضافی گنجائش نہیں ملتی۔

نوٹس

قیمتیں: Elliptic $0.98، BitOK $0.50 فی چیک، کٹوتی کے وقت کے ریٹ پر TRX بیلنس سے کاٹے جاتے ہیں۔
پروسیسنگ کا وقت: زیادہ تر چیکس چند سیکنڈوں میں مکمل ہو جاتے ہیں؛ طویل تاریخ والا ایڈریس تین منٹ تک لے سکتا ہے۔ غیر مطابقت پذیر (asynchronous) موڈ کا استعمال کریں اور نتیجہ GET /apiv2/screening/{client_order_id} کے ساتھ پڑھیں۔
غیر فعال ایڈریسز skipped لوٹاتے ہیں اور ان سے کوئی کٹوتی نہیں کی جاتی۔
فراہم کنندہ کا کچا (raw) جواب کبھی واپس نہیں کیا جاتا۔ provider_data ایک نظر ثانی شدہ پروجیکشن ہے؛ وہ فیلڈز جو اسکرین کیے گئے ایڈریس کے بجائے فراہم کنندہ کے ساتھ ہمارے اکاؤنٹ سے تعلق رکھتی ہیں، کسی پر ظاہر نہیں کی جاتیں۔

رپورٹس

اینڈ پوائنٹ JSON لوٹاتا ہے اور کچھ نہیں۔ کوئی PDF اور کوئی Markdown نہیں ہے۔

ایک رپورٹ جن تمام اجزاء پر مشتمل ہوتی ہے وہ پہلے ہی جواب میں موجود ہیں: متحد بلاک اور provider_data۔ اسے اپنی طرف رینڈر کرنے سے آپ کو وہ دستاویز ملتی ہے جو آپ اصل میں چاہتے ہیں — آپ کی برانڈنگ، آپ کی زبان، آپ کا لے آؤٹ — خاص طور پر اگر آپ چیکس کو دوبارہ فروخت کرتے ہیں، کیونکہ ہمارے نام پر مشتمل رپورٹ آپ کے اپنے گاہک کو دینے کے لیے غلط دستاویز ہے۔

اگر آپ کو کسی تیسرے فریق کے لیے ثبوت کے طور پر رپورٹ کی ضرورت ہے — ایک بینک، ایک ریگولیٹر، ایک فریق ثانی — تو نوٹ کریں کہ ایک غیر دستخط شدہ PDF ثبوت نہیں ہوتی چاہے اسے کوئی بھی تیار کرے: اسے ایک منٹ میں ٹیکسٹ ایڈیٹر میں تبدیل کیا جا سکتا ہے۔ ایک قابل تصدیق شے کو دستخط یا عوامی تصدیقی صفحے کی ضرورت ہوتی ہے، اور وہ ایک مختلف فیچر ہے۔ اگر آپ کا یہ معاملہ ہے، تو ہمیں بتائیں کہ آپ کے فریق ثانی کو کیا درکار ہے۔

انہی چیکس کے لیے Netts ڈیش بورڈ میں سترہ زبانوں میں پڑھنے کے قابل PDF رپورٹس واقعی موجود ہیں۔

یہ بھی دیکھیں

GET /apiv2/screening/{client_order_id} — ایک چیک پڑھیں
GET /apiv2/screening/history — آپ کے چیکس، کرسر کے ساتھ صفحات پر مشتمل
GET /apiv2/screening/providers — فراہم کنندگان، قیمتیں، نیٹ ورکس، پیمانے
GET /apiv2/screening/price — ایک فراہم کنندہ کی قیمت
Sanctions in an AML result — sanctions کیا کہتا ہے اور فراہم کنندہ کا فلیگ کیا کہتا ہے

POST /apiv2/screening ​

Endpoint کا URL ​

درخواست کے Headers ​

درخواست کا Body ​

پیرامیٹرز ​

نمونہ درخواستیں ​

cURL — نتیجے کا انتظار کریں ​

cURL — قبول کریں اور پول (poll) کریں ​

Python ​

جواب کے کوڈز ​

جواب ​

فیلڈز کا سیٹ کبھی تبدیل نہیں ہوتا ​

order ​

billing ​

precheck ​

check ​

risk ​

exposure[]، rules[]، entities[] ​

شیئرز کسر (fractions) ہیں، کبھی فیصد نہیں ​

اعداد اسٹرنگز ہیں ​

حالیہ نتیجے کا دوبارہ استعمال ​

Idempotency ​

نقائص ​

وہ نقائص جو اس فارمیٹ کو استعمال نہیں کرتے ​

Rate Limits ​

نوٹس ​

رپورٹس ​

یہ بھی دیکھیں ​

POST /apiv2/screening

Endpoint کا URL

درخواست کے Headers

درخواست کا Body

پیرامیٹرز

نمونہ درخواستیں

cURL — نتیجے کا انتظار کریں

cURL — قبول کریں اور پول (poll) کریں

Python

جواب کے کوڈز

جواب

فیلڈز کا سیٹ کبھی تبدیل نہیں ہوتا

`order`

`billing`

`precheck`

`check`

`risk`

`exposure[]`، `rules[]`، `entities[]`

شیئرز کسر (fractions) ہیں، کبھی فیصد نہیں

اعداد اسٹرنگز ہیں

حالیہ نتیجے کا دوبارہ استعمال

Idempotency

نقائص

وہ نقائص جو اس فارمیٹ کو استعمال نہیں کرتے

Rate Limits

نوٹس

رپورٹس

یہ بھی دیکھیں