Uğurlu market data API integration əvvəlcə “hansı API daha ucuzdur?” sualından yox, məhsulun istifadəçiyə hansı bazar məlumatını, hansı sürətlə və hansı hüquqlarla göstərəcəyindən başlayır. Forex və kripto analitika platformasında data qrafiklərin, screener-lərin, xəbərdarlıqların, indekslərin və istifadəçi etibarının əsas qatıdır. Yanlış provayder və ya birbaşa frontend inteqrasiyası sonradan baha başa gələn lisenziya, performans və keyfiyyət riskləri yarada bilər.

Ən praktik yanaşma budur: provayderi yalnız endpoint siyahısı ilə deyil, məhsul tələbləri, hüquqi istifadə ssenarisi və dayanıqlı inteqrasiya arxitekturası ilə birlikdə qiymətləndirin. POLADO-nun FinTech və trading sistemləri xidməti məhz bu mərhələdə tələblərin formalaşdırılmasından inteqrasiya, analitika və əməliyyat monitorinqinə qədər kömək edə bilər.

1. Əvvəlcə platformanızın bazar məlumatı modelini dəqiqləşdirin

“Forex data” və “crypto data” vahid məhsul deyil. Məsələn, spot kriptoda birja üzrə son trade qiyməti, bid/ask, order book və şamlar ayrı məlumat növləridir. Forex-də isə provayderin qiyməti banklararası bazarın vahid rəsmi qiyməti deyil, öz likvidlik mənbələri və ya aqreqasiya metodundan yaranan kotirovka ola bilər. Buna görə vendor müqayisəsindən əvvəl data müqaviləsi hazırlayın.

  • İnstrumentlər: FX cütləri, spot kripto cütləri, perpetual futures, indekslər və ya xüsusi watchlist-lər.
  • Bazar mənşəyi: hər birja üçün ayrıca qiymət, seçilmiş birjalardan aqreqasiya edilmiş qiymət, yoxsa konkret broker/feed.
  • Məlumat növü: last trade, bid/ask, OHLCV, trade-lər, top-of-book, dərin order book, funding rate və open interest.
  • İstifadəçi ssenarisi: gecikməyə həssas trading workflow, bir neçə saniyəlik dashboard, yoxsa tarixi araşdırma və backtesting.
  • Coğrafiya və istifadəçi tipi: daxili komanda, qeydiyyatlı son istifadəçi, ödənişli abunəçi və ya müəssisə müştərisi.

Bu siyahı “bizə real-time lazımdır” kimi qeyri-müəyyən tələbi ölçülə bilən qərara çevirir. Məsələn, 15 dəqiqə gecikmə analitika üçün yetərli ola bilər, lakin istifadəçi real-time xəbərdarlıq və ya order-book vizuallaşdırması görürsə, həmin kompromis uyğun deyil.

2. Əhatə dairəsini simvolların sayı ilə yox, semantika ilə müqayisə edin

Provayder kataloqunda BTC/USD görünməsi kifayət deyil. Bu simvolun hansı venue-dan gəldiyini, quote valyutasını, spot yoxsa törəmə alət olduğunu, həcm vahidini və delist edilmiş instrumentlərin tarixçədə necə saxlanıldığını öyrənin. Eyni məntiq Forex data API üçün də keçərlidir: EUR/USD kotirovkasının source-u, bid/ask mövcudluğu, sessiya davranışı və həftəsonu boşluqları nəticələrə təsir edir.

Vendor demo zamanı soruşulacaq suallar

  • Instrument reference data və aktiv/passiv statusu API-dən alınırmı?
  • Şamlar vendor tərəfindən hazırlanır, yoxsa raw trade-lərdən sizin tərəfdə qurula bilər?
  • Volume base asset, quote asset, kontrakt sayı, yoxsa başqa vahidlə verilir?
  • Trade, quote və candle timestamp-ləri nəyi ifadə edir: event time, vendor qəbul vaxtı, yoxsa cavabın yaradıldığı an?
  • Symbol rename, chain migration, fork, redenomination və delisting üçün qayda nədir?

Bu detal xüsusilə multi-exchange kripto məhsullarında vacibdir. İstifadəçi “BTCUSDT” görərkən onun hansı birjada olduğunu bilməlidir; əks halda müxtəlif likvidlik və qiymətləri bir instrument kimi təqdim etmək səhv analitik nəticə yarada bilər.

3. Lisenziya və redistribution hüquqlarını texniki işdən əvvəl yoxlayın

Data texniki cəhətdən əlçatan olsa da, onu son istifadəçilərə göstərmək, saxlamaq, yenidən ötürmək və ya həmin məlumat əsasında törəmə analitika təqdim etmək planınızın lisenziyaya uyğun olduğu demək deyil. Müqavilədə display və non-display istifadəni, daxili və xarici istifadəçini, real-time və delayed məlumatı, regionları, peşəkar istifadəçi kateqoriyalarını, cache və tarixçənin saxlanma müddətini ayrıca yoxlayın.

Hüquqi və məhsul komandası üçün sadə qayda: “API açarımız işləyir” ifadəsi redistribution icazəsi deyil. Həmçinin chart, indikator, siqnal kimi təqdim olunan hesablamaların data müqaviləsində “derived works” məhdudiyyətinə düşüb-düşmədiyini yazılı şəkildə təsdiqləyin. Platforma investisiya siqnalı və ya gəlir vədi deyil; məlumatın mənşəyi, gecikməsi və əhatə dairəsi istifadəçiyə aydın təqdim edilməlidir.

4. Market data latency-ni SLO kimi təyin edin

“Real-time” marketinq sözü deyil, ölçülən servis səviyyəsidir. Sizə ən azı üç zaman damğası lazımdır: mənbədə hadisə vaxtı, sizin sistemin məlumatı qəbul etdiyi vaxt və istifadəçiyə çatdırıldığı vaxt. Bu fərqlər əsasında freshness və end-to-end latency ölçülür.

  • Dashboard: yenilənmə tezliyi, məsələn 1–5 saniyə, çox vaxt istifadəçi təcrübəsi üçün kifayət edir.
  • Alert: maksimum qəbul edilən gecikmə, burst zamanı davranış və təkrar bildiriş qaydası ayrıca yazılmalıdır.
  • Trading workflow: yalnız qiymət gecikməsi deyil, sequence gap, reconnect və snapshot bərpası da risk modelinə daxildir.

Vendorun “low latency” iddiası əvəzinə öz sınağınızı aparın: hədəf regiondan WebSocket bağlantısı, pik vaxtlarda message lag, reconnect müddəti, REST backfill sürəti və subscription limitlərini ölçün. Bir çox API request weight və connection limitləri tətbiq edir; buna görə frontend istifadəçilərinin hamısını vendor WebSocket-ə birbaşa qoşmaq həm limit, həm də təhlükəsizlik riski yaradır.

5. Vendor feed-ini birbaşa hər frontend-ə verməyin

Sağlam arxitekturada provayder connector-ları backend-də işləyir, məlumat daxili kanonik modelə çevrilir, sonra isə məhsul API-si və ya nəzarət olunan WebSocket gateway vasitəsilə web və mobil tətbiqlərə çatdırılır. Bu qatın məqsədi sadəcə API açarını gizlətmək deyil.

  1. Giriş və xərc nəzarəti: bir upstream subscription çox sayda istifadəçiyə paylana, subscription-lar və cache idarə oluna bilər.
  2. Vendor asılılığının azalması: UI bir provayderin symbol formatına, payload sahələrinə və reconnect xüsusiyyətlərinə bağlanmır.
  3. Ardıcıllıq: bütün məhsulda vahid instrument ID, timestamp, precision və OHLCV qaydası istifadə edilir.
  4. Təhlükəsizlik: vendor credential-ları brauzerə və mobil tətbiqə çıxmır; istifadəçi entitlement-ləri sizin tərəfdə tətbiq edilir.
  5. Dayanıqlılıq: cache, throttling, stale-data xəbərdarlığı və ikinci mənbəyə keçid mərkəzləşdirilir.

Bu yanaşma POLADO-nun ESFX və FT10 kimi FinTech/analitika kateqoriyasındakı işlərdən çıxan məhsul mühəndisliyi prinsipinə uyğundur: data qatını UI-dan ayırmaq, məhsulun sonrakı inteqrasiya və inkişaf imkanlarını qoruyur.

6. Financial data normalization ayrıca iş paketidir

İki feed eyni sahə adından istifadə etsə də, eyni məna daşımaya bilər. Normalizasiya qatında kanonik instrument registry, vendor symbol mapping, decimal precision, timezone və timestamp siyasəti, currency/contract metadata və source attribution saxlanmalıdır.

Məsələn, daxili modelinizdə instrument_id, asset class, base, quote, venue, instrument type, price increment və status kimi sabit sahələr olsun. Vendor adapter-i “BTCUSDT” və ya başqa formatı həmin daxili ID-yə xəritələndirir. Heç vaxt yalnız string concatenate etməklə simvol yaratmayın: leverage token, perp, inverse contract və köhnəlmiş simvollar bu fərziyyəni pozur.

Minimum data validation qaydaları

  • Qiymət mənfi və ya sıfır olmamalıdır; instrument üzrə məntiqli tick ölçüsü yoxlanmalıdır.
  • Bid ask-dan yüksəkdirsə, hadisəni flag edin və ya göstərməyin.
  • Timestamp həddindən artıq köhnədirsə, məlumatı stale kimi işarələyin.
  • OHLCV üçün high/low/open/close ardıcıllığını və interval sərhədlərini yoxlayın.
  • Sequence nömrəsi olan feed-lərdə gap aşkar ediləndə snapshot + delta bərpası edin.

7. Tarixi məlumat və failover planını sübutla qiymətləndirin

Backtesting və uzunmüddətli chart üçün data keyfiyyəti təkcə “beş illik tarixçə” deyil. Missing interval-lar, duplicate trade-lər, sonradan dəyişdirilən candle-lar, delist edilmiş cütlər və korporativ/asset hadisələrinin necə idarə olunduğunu nümunə dataset ilə yoxlayın. Öz data keyfiyyət hesabatınızı qurun: hər instrument üzrə coverage, gap, gecikmiş hadisə və vendor düzəlişlərini izləyin.

Failover üçün əvvəlcədən qərar verin: ikinci provayder eyni metodologiyada məlumat verirmi? Qiymətlər fərqlənəndə hansını göstərirsiniz? Primary qayıdanda dərhal switch edirsiniz, yoxsa sabitlik pəncərəsi gözləyirsiniz? Failover həmişə “eyni qiymət” demək deyil; istifadəçiyə source və data statusunu şəffaf göstərmək daha doğrudur.

Seçimdən əvvəl yekun checklist

  • Hədəf instrumentlər, venue-lar və data növləri yazılı şəkildə təsdiqlənib.
  • Display, redistribution, cache, tarixçə və derived analytics hüquqları hüquqi baxışdan keçib.
  • Latency, freshness, uptime və recovery üçün ölçülə bilən SLO-lar mövcuddur.
  • Rate limit, reconnect, backfill və burst ssenariləri test edilib.
  • Symbol mapping, normallaşdırma və validation qaydaları dizayn olunub.
  • Vendor outage üçün cache, stale status və failover runbook hazırlanıb.
  • Frontend vendor feed-ə deyil, sizin təhlükəsiz data gateway-inizə qoşulur.

Baku FinTech development layihəniz üçün provayder seçimi, market-data arxitekturası və etibarlı dashboard/trading workflow planı lazımdırsa, POLADO ilə əlaqə saxlayın. Komandamız platformanı investisiya tövsiyəsi verən məhsul kimi deyil, izlənə bilən, təhlükəsiz və genişlənə bilən maliyyə texnologiyası kimi layihələndirməyə kömək edir.