إشعار تجريبي: وثائق واجهة برمجة التطبيقات (API) هذه تجريبية. قد تتغير نقاط النهاية والحقول ورموز الأخطاء والسلوكيات دون إشعار، ولا يتم ضمان التوافق مع الإصدارات السابقة. تجنب الاعتماد عليها في سير العمل الإنتاجي الحرج.

البدء مع واجهة برمجة التطبيقات RESTful الخاصة بنا

صُمّم Dynadot API ليتكامل بسلاسة مع أنظمتك. تتميز واجهة API الخاصة بنا بعناوين URL متوقعة وموجهة نحو الموارد، وتدعم أجسام طلبات مُشفّرة بصيغة JSON، وتُرجع استجابات مُشفّرة بصيغة JSON وXML، وتلتزم بطرق HTTP القياسية، والمصادقة، ورموز الاستجابة.

يمكنك استخدام Dynadot API في وضعي الاختبار والمباشر. يتم تحديد الوضع بواسطة مفتاح API المستخدم لمصادقة طلباتك. يتيح لك وضع الاختبار محاكاة تكامل API والتحقق منه دون التأثير على البيانات المباشرة أو المعاملات.

Dynadot API يتركز بشكل أساسي على إدارة النطاقات، ومعالجة الطلبات، والخدمات المرتبطة. تقدر تسوي إجراءات مثل تسجيل النطاقات ونقلها وتجديدها، وإدارة إعدادات DNS، وعرض أو تحديث طلبات الحساب.

يرجى الملاحظة: عمليات الإنشاء والتحديث والحذف المجمّعة غير مدعومة، ويقتصر كل نوع من هذه الطلبات على كائن أو إجراء واحد.

إنشاء مفاتيح API الخاصة بك

قبل أن تبدأ في إجراء أي طلبات API، من الضروري إنشاء مفتاح API وسر API.

هذه المفاتيح مطلوبة للمصادقة ولضمان أمان إجراءاتك عند التفاعل مع واجهة API لدينا.

يمكنك توليد كل من مفتاح API وسر API عبر قسم API في إعدادات حسابك.

1. سجّل الدخول إلى حسابك في Dynadot.

2. انتقل إلى الأدوات > API.

3. قم بإنشاء مفتاح API و سر API من هذه الصفحة.

انضم إلى مجتمعنا

هل لديك أي أفكار أو اقتراحات؟ تحدث مباشرة مع مهندسينا المحترفين.

ديسكورد

طريقة HTTP

تستخدم واجهة برمجة التطبيقات طرق HTTP القياسية لتنفيذ العمليات على الموارد:

الطريقةوصف
GETطلب GET: استرداد معلومات تفصيلية حول مورد محدد
POSTطلب POST: إنشاء مورد جديد
PUTطلب PUT: تحديث المورد المحدد بالكامل
DELETEطلب DELETE: إزالة المورد المحدد

URL

عنوان URL الأساسي لجميع طلبات API هو:

https://api.dynadot.com/

تنسيق عنوان URL الكامل:

http://api.dynadot.com/restful/version_code/resource/{resource_identify}/action
مثال :
https://api.dynadot.com/restful/v2/domains/{domain_name}/search

الإصدار

الإصدار الحالي من API هو v2.0.0

لما تبني رابط طلب API، يكفي إنك تحط الإصدار الرئيسي. التحديثات الفرعية والتصحيحية مصممة تكون متوافقة مع الإصدارات السابقة، وما راح تجيب تغييرات تكسر الكود الموجود عندك. هذا يضمن الاستقرار ويخليك تستفيد من التحسينات والإصلاحات التدريجية بدون ما تحتاج تعدل تطبيقك.

عند إصدار إصدارات مستقبلية، سنحافظ على التوافق مع الإصدارات الأقدم لفترة من الوقت. سيتم تقديم ميزات جديدة وتغييرات كاسرة في زيادات الإصدارات الرئيسية.

رأس

تحتوي ترويسة طلب API على بيانات وصفية عن الطلب. توفّر هذه البيانات الوصفية سياقًا أساسيًا لكي يعالج الخادم الطلب بشكل صحيح. ومن الترويسات الشائعة الاستخدام:

Content-Type

يحدد تنسيق البيانات المُرسَلة في جسم الطلب. يستخدم الخادم هذه المعلومات لتحليل الطلب بشكل صحيح. القيمة المقبولة الوحيدة حاليًا هي: application/json

مثال :
Content-Type: application/json

قبول

يُعلِم الخادم بتنسيق الاستجابة المتوقع من العميل.

القيم الممكنة: application/json, application/xml

مثال :
Accept: application/json

التفويض

يجب أن تتضمن جميع طلبات API مفتاح API للمصادقة. يمكنك الحصول على مفتاح API الخاص بك من لوحة تحكم حسابك.

يمكنك إنشاء مفتاح API في صفحة إعدادات API
مثال على ترويسة المصادقة:
Authorization: Bearer YOUR_API_KEY

X-Request-ID

ترويسة X-Request-ID هي ترويسة (اختياري) تُستخدم لتحديد كل طلب API بشكل فريد. عند تضمينها، تساعد هذه الترويسة في تتبع الطلبات وربطها عبر الأنظمة والسجلات، مما يسهل تصحيح أخطاء نشاط API ومراقبته.

يجب أن تكون قيمة X-Request-ID عبارة عن UUID صالح (معرّف فريد عالميًا)، وفقًا للتنسيق القياسي: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (مثال، 123e4567-e89b-12d3-a456-426614174000).

مثال :
X-Request-ID: 550e8400-e29b-41d4-a716-446655440000

X-Signature جديد

هيدر X-Signature هو آلية أمان إلزامية للطلبات التعاملية، بما فيها اللي تجيب معلومات حساسة أو تحدّث البيانات. يضمن الأصالة والتكامل وعدم الإنكار لطلبات API من خلال إلزام العملاء بتوقيع حمولة الطلب باستخدام HMAC-SHA256.

لإنشاء التوقيع، ستحتاج إلى القيم التالية

1. مفتاح API: مفتاح API الفريد الخاص بك.

2. المسار الكامل والاستعلام: المسار الكامل لنقطة نهاية API مع معاملات الاستعلام.

3. X-Request-Id: معرّف الطلب. إذا لم يكن متاحًا، يمكنك إدخال سلسلة فارغة.

4. جسم الطلب: جسم الطلب. إذا كان فارغًا أو null، يمكنك إدخال سلسلة فارغة.

السلسلة المطلوب توقيعها هي مزيج من القيم المذكورة أعلاه، مدمجة بالترتيب التالي:

apiKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)
مثال
apiKey = "your_api_key"
fullPathAndQuery = "/restful/v2/some/endpoint?param=value"
xRequestId = "unique-request-id"
requestBody = "{\"key\":\"value\"}"

stringToSign = "your_api_key\n/restful/v2/some/endpoint?param=value\nunique-request-id\n{\"key\":\"value\"}"
إنشاء توقيع HMAC-SHA256

بعد إنشاء stringToSign, احسب التوقيع باستخدام HMAC-SHA256 مع سر الخاص بك كمفتاح, ثم ترميز Base64 النتيجة.

يتم إنشاء التوقيع باستخدام الخطوات التالية:

1. استخدم خوارزمية HMAC-SHA256.

2. استخدم stringToSign (UTF-8) كرسالة الإدخال.

3. استخدم السر الخاص بك (UTF-8) كمفتاح.

4. قم بترميز ناتج HMAC باستخدام Base64 (Base64 القياسي)

طبّق التوقيع الذي تم إنشاؤه كقيمة لـ X-Signature في ترويسة الطلب

Example :
X-Signature: {HMAC-SHA256 Signature}
Example Code :
import base64
import hashlib
import hmac
import uuid

def create_signature(api_key, api_secret, full_path_and_query, x_request_id, request_body=""):
    string_to_sign = (
        api_key + "\n" +
        full_path_and_query + "\n" +
        (x_request_id or "") + "\n" +
        (request_body or "")
    )

    digest = hmac.new(
        api_secret.encode("utf-8"),
        string_to_sign.encode("utf-8"),
        hashlib.sha256
    ).digest()

    return base64.b64encode(digest).decode("utf-8")

api_key = "your_api_key"
api_secret = "your_secret"
full_path_and_query = "/restful/v2/accounts/info"
x_request_id = str(uuid.uuid4())
request_body = ""

x_signature = create_signature(
    api_key,
    api_secret,
    full_path_and_query,
    x_request_id,
    request_body
)

print("X-Request-ID:", x_request_id)
print("X-Signature:", x_signature)

النص

يُستخدم جسم طلب API لإرسال البيانات إلى الخادم. ويُضمَّن عادةً في طلبات POST أو PUT أو PATCH (وليس عادةً في طلبات GET أو DELETE).

تنسيق المحتوى

يتم تحديد تنسيق بيانات النص بواسطة رأس Content-Type. تتضمن بعض التنسيقات الشائعة:

JSON

حالات الاستخدام النموذجية

طلبات POST: تُستخدم طريقة POST لإنشاء مورد جديد على الخادم. عادةً ما يحتوي جسم الطلب على تفاصيل المورد..

طلبات PUT: تُستخدم طريقة PUT لتحديث مورد موجود عبر استبداله بالكامل. يحتوي جسم الطلب على المورد المحدّث الكامل.

طلبات DELETE: تُستخدم طريقة DELETE لإزالة مورد موجود من الخادم. لا يحتوي على جسم طلب.

طلبات GET: تُستخدم طريقة GET لاسترداد مورد موجود من الخادم. لا يحتوي على جسم طلب

تنسيق الاستجابة

تُعاد جميع استجابات API إما بصيغة JSON أو XML، ويُحدد تنسيق بيانات الجسم بواسطة ترويسة Accept، مما يوفّر البيانات المطلوبة أو رسالة خطأ، إن كان ذلك مناسبًا.

تنسيق المحتوى

تحتوي الاستجابة بشكل عام على 3 أجزاء: الكود، الرسالة، البيانات

الرمز: حالة الطلب

رسالة: مزيد من الوصف للحالة

بيانات: جسم الاستجابة

JSON/XML

معالجة الأخطاء

رموز حالة HTTP هي أرقام قياسية من ثلاث خانات يُعيدها الخادم للإشارة إلى نتيجة طلب العميل. وتوفّر معلومات أساسية عمّا إذا كانت المعالجة قد تمت بنجاح، أو كان الطلب يتطلب إجراءً إضافيًا، أو واجه خطأً. وتنقسم هذه الرموز إلى خمس فئات، تمثّل كلّ منها نوعًا مميزًا من الاستجابة.

تتوافق رموز الحالة الخاصة بواجهة برمجة التطبيقات (API) لدينا مع بروتوكول HTTP/1.1، وهو معيار مقبول على نطاق واسع يضمن اتصالاً متسقًا وموثوقًا. باستخدام HTTP/1.1، نستفيد من ميزات مثل الاتصالات الدائمة والتخزين المؤقت المحسّن لتحسين تفاعلات العميل والخادم.

2xx (ناجح): يشير إلى أن الأمر تم استلامه وقبوله.
4xx (خطأ العميل): يشير إلى أن العميل ارتكب خطأ في الطلب, مثل تقديم إدخال غير صالح أو افتقاره إلى التفويض المناسب.
5xx (خطأ في الخادم): يشير إلى أن الخادم واجه خطأ أو غير قادر على تلبية الطلب.

نظرة عامة على Webhook

تعد Webhooks أداة قوية لأتمتة العمليات ودمج الأنظمة. فهي تتيح لك تلقي إشعارات فورية حول الأحداث أو التغييرات في حسابك أو إعدادات نطاقك. من خلال تهيئة Webhooks، يمكنك تشغيل إجراءات في أنظمة خارجية، أو تحديث قواعد البيانات، أو إرسال إشعارات بناءً على أحداث محددة.

يدعم Dynadot API إشعارات webhook لمختلف الأحداث، مثل تسجيل النطاقات ونقلها وتجديدها وانتهاء صلاحيتها، حتى تتمكن من اتخاذ الإجراءات المناسبة استجابةً لذلك.

لاستخدام الويب هوكس، تحتاج إلى توفير نقطة نهاية URL حيث سيتم إرسال الإشعارات. يمكنك تهيئة عنوان URL الخاص بالويب هوك، والمفتاح، والسر في إعدادات حسابك. عند وقوع حدث، سيرسل Dynadot طلب POST إلى عنوان URL المحدد مع البيانات ذات الصلة.

رأس طلب Webhook

تحتوي ترويسة طلب Webhook على بيانات وصفية عن الطلب. توفر هذه البيانات الوصفية سياقًا أساسيًا ليعالج الخادم الطلب بشكل صحيح. تتضمن الترويسات الشائعة ما يلي:

Content-Type

يحدد تنسيق البيانات المُرسَلة في جسم الطلب. يستخدم الخادم هذه المعلومات لتحليل الطلب بشكل صحيح. القيمة المقبولة الوحيدة حاليًا هي: application/json

مثال :
Content-Type: application/json

التفويض

ستتضمن جميع طلبات Webhook مفتاح Webhook للمصادقة. يمكنك الحصول على مفتاح Webhook الخاص بك من لوحة تحكم حسابك.

يمكنك إدارة WEBHOOK_KEY الخاص بك في صفحة إعدادات API.
مثال على ترويسة المصادقة:
Authorization: Bearer WEBHOOK_KEY

X-Signature

إن ترويسة X-Signature هي آلية أمنية إلزامية لطلبات المعاملات، بما في ذلك تلك التي تسترجع معلومات حساسة أو تحدّث البيانات. وهي تضمن أصالة وسلامة وعدم إنكار طلبات Webhook من خلال مطالبة العملاء بتوقيع حمولة الطلب باستخدام HMAC-SHA256.

لإنشاء التوقيع، ستحتاج إلى القيم التالية

1. مفتاح WEBHOOK: مفتاح WEBHOOK الفريد الخاص بك.

2. المسار الكامل والاستعلام: المسار الكامل لنقطة نهاية WEBHOOK بالإضافة إلى معاملات الاستعلام.

3. X-Request-Id: معرّف الطلب. إذا لم يكن متاحًا، يمكنك إدخال سلسلة فارغة.

4. جسم الطلب: جسم الطلب. إذا كان فارغًا أو null، يمكنك إدخال سلسلة فارغة.

السلسلة المطلوب توقيعها هي مزيج من القيم المذكورة أعلاه، مدمجة بالترتيب التالي:

webhookKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)
مثال
webhookKey = "your_webhook_key"
fullPathAndQuery = "/v2/some/endpoint?param=value"
xRequestId = "unique-request-id"
requestBody = "{\"key\":\"value\"}"

stringToSign = "your_webhook_key\n/v2/some/endpoint?param=value\nunique-request-id\n{\"key\":\"value\"}"
إنشاء توقيع HMAC-SHA256

بعد إنشاء stringToSign, احسب التوقيع باستخدام HMAC-SHA256 مع سر الخاص بك كمفتاح, ثم ترميز Base64 النتيجة.

يتم إنشاء التوقيع باستخدام الخطوات التالية:

1. استخدم خوارزمية HMAC-SHA256.

2. استخدم stringToSign (UTF-8) كرسالة الإدخال.

3. استخدم السر الخاص بك (UTF-8) كمفتاح.

4. قم بترميز ناتج HMAC باستخدام Base64 (Base64 القياسي)

طبّق التوقيع الذي تم إنشاؤه كقيمة لـ X-Signature في ترويسة الطلب

Example :
X-Signature: {HMAC-SHA256 Signature}
Example Code :
import base64
import hashlib
import hmac
import uuid

def create_signature(webhook_key, webhook_secret, full_path_and_query, x_request_id, request_body=""):
    string_to_sign = (
        webhook_key + "\n" +
        full_path_and_query + "\n" +
        (x_request_id or "") + "\n" +
        (request_body or "")
    )

    digest = hmac.new(
        webhook_secret.encode("utf-8"),
        string_to_sign.encode("utf-8"),
        hashlib.sha256
    ).digest()

    return base64.b64encode(digest).decode("utf-8")

webhook_key = "your_webhook_key"
webhook_secret = "your_secret"
full_path_and_query = "/v2/some/webhook/path"
x_request_id = str(uuid.uuid4())
request_body = ""

x_signature = create_signature(
    webhook_key,
    webhook_secret,
    full_path_and_query,
    x_request_id,
    request_body
)

print("X-Request-ID:", x_request_id)
print("X-Signature:", x_signature)

تنسيق طلب Webhook

تنسيق المحتوى

يحتوي جسم طلب الويب هوك على معلومات حول الحدث الذي أطلق الإشعار. يتم تحديد تنسيق بيانات الجسم بواسطة ترويسة Content-Type، والتي تكون عادةً application/json.

يتضمن جسم الطلب المعاملات التالية:

مثال:

JSON/XML

المعلمات

يحتوي جسم الطلب على المعاملات التالية:

معاملوصف
الحدثنوع الحدث الذي فعّل الإشعار.
معرّف الحدثمعرّف الحدث الذي أطلق الإشعار.
الطابع الزمنيالطابع الزمني عند وقوع الحدث.
بياناتالبيانات المرتبطة بالحدث.

تنسيق استجابة Webhook

تنسيق المحتوى

سيتم إرسال الرد على طلب webhook بتنسيق JSON، اعتمادًا على ترويسة Content-Type المحددة في الطلب.

يحتوي جسم الاستجابة على معلومات حول حالة الطلب، مثل ما إذا تمت معالجته بنجاح أو واجه خطأً.

الرد بشكل عام يحتوي على جزء واحد: الحالة

مثال:

JSON/XML

تحديد معدل الطلبات

لازم تتبعت الطلبات عبر https (سوكيت آمن) للأمان. بس طلب واحد ينقدر يتعالج بنفس الوقت، فلو سمحت استنى طلبك الحالي يخلص قبل ما تبعث طلب ثاني.

ستتلقى أعدادًا مختلفة من الخيوط بناءً على مستوى السعر لحسابك:

مستوى السعرعدد الخيوطحد المعدل
عاديخيط واحد60/دقيقة (1/ثانية)
حساب Bulk5 مواضيع600/دقيقة (10/ثانية)
حجم كبير فائق35 خيطًا6000/دقيقة (100/ثانية)

ملاحظة: place_auction_bid & get_auction_bid معفيان حاليًا من حد المعدل أعلاه.

مثال :

بالنسبة إلى أمر تقييم النطاق، ستتلقى أعدادًا مختلفة من الطلبات المسموح بها بناءً على مستوى سعر حسابك:

مستوى السعرحد المعدل
عادي50/يوم
حساب Bulk100/يوم
حجم كبير فائق300/يوم
مثال :

Sandbox

تتيح بيئة Dynadot API Sandbox لك اختبار تكاملات API الخاصة بك بأمان دون التأثير على حسابك المباشر أو أموالك الحقيقية.

كيفية الوصول إلى بيئة الاختبار

1. سجّل الدخول إلى حساب Dynadot الخاص بك وانتقل إلى صفحة إعدادات API:

2. https://www.dynadot.com/account/domain/setting/api.html

3. أنشئ مفتاح API Sandbox والمفتاح السري لـ API Sandbox.

4. بعد الإنشاء، يرجى منح النظام بعض الوقت لتفعيل مفاتيح sandbox الخاصة بك وإنشاء حساب Sandbox الخاص بك.

5. سيتم تمويل حساب Sandbox الخاص بك مسبقًا برصيد 10,000 بجميع العملات المدعومة لأغراض الاختبار.

استخدام Sandbox API

أوامر API في بيئة Sandbox متطابقة وظيفيًا مع بيئة الإنتاج.

الفرق الوحيد هو عنوان URL الأساسي:

عنوان URL لواجهة API للإنتاج: https://api.dynadot.com

رابط API للبيئة التجريبية: https://api-sandbox.dynadot.com

ملاحظات مهمة

بعض أوامر API قد تكون غير متاحة في بيئة Sandbox. يرجى الرجوع إلى وثائق الأمر المحدد للتحقق من تسمية "دعم بيئة اختبار API".

تم تصميم Sandbox بشكل أساسي للاختبار. قد تختلف بعض الأوامر عن الإنتاج، وقد تجد Sandbox لا يمكن محاكاة جميع السيناريوهات المعقدة المحتملة بشكل كامل في بيئة الإنتاج.

نظرة عامة على سجل التغييرات

سجل التغييرات هو سجل مفصل للتغييرات والتحسينات وإصلاحات الأخطاء والميزات الجديدة التي تم تقديمها في كل إصدار من واجهة API. وهو يوفر الشفافية للمستخدمين والمطورين من خلال توثيق تأثير كل تحديث. ويتكون من جزأين رئيسيين:

إصدار API

يسلط هذا الجزء الضوء على نظام إدارة الإصدارات في API, مما يساعد المطورين على تتبع تطور الميزات وضمان التوافق. يتم تعريف كل إصدار API برقم إصدار فريد (مثل v1.0.1, v2.2.3) ويمثل علامة فارقة أو إصدارًا مهمًا. تتيح إدارة الإصدارات للمستخدمين الحفاظ على تكاملاتهم بأقل قدر من التعطيل من خلال اختيار التحديثات عند الاستعداد.

سجل التغييرات

يوفر سجل التغييرات معلومات مفصّلة حول التحديثات، وإصلاحات الأخطاء، والميزات المهملة، والتحسينات التي أُدخلت في كل إصدار. ويوضّح التغييرات المحدّدة التي أُجريت على نقاط النهاية، أو المعاملات، أو آليات المصادقة، أو تنسيقات الاستجابة. يضمن هذا القسم حصول المطورين على شفافية كاملة بشأن ما تغيّر، وتمكّنهم من تعديل تطبيقاتهم وفقًا لذلك. ومن خلال الحفاظ على سجل تغييرات واضح ومفصّل، نهدف إلى تزويد المطورين بالأدوات والمعلومات اللازمة لإدارة عمليات التكامل بفعالية وثقة.

إصدار API

واجهة API لدينا حاليًا في الإصدار v2.0.0

تُستخدم رموز الإصدار لتحديد تحديثات API وإدارتها بشكل منهجي. وهي تتبع تنسيق الإصدار الدلالي (SemVer):

<Major><Minor><Patch>

يخدم كل مكون من مكونات رمز الإصدار غرضًا محددًا ويساعد المطورين على توصيل نطاق التغييرات ونوعها بفعالية.

الإصدار الرئيسي

التعريف: يمثل تغييرات كبيرة قد تكسر التوافق مع الإصدارات السابقة.

التنسيق:

x.<Minor>.x
أمثلة: v1.0.0 -> v2.0.0: إعادة تصميم كاملة لواجهة برمجة التطبيقات أو تغييرات غير متوافقة في المخطط.

إصدار ثانوي

التعريف: يشير إلى إضافات ميزات متوافقة مع الإصدارات السابقة.

التنسيق:

x.<Minor>.x
أمثلة: v1.0.0 -> v1.1.0: إضافة نقاط نهاية أو طرق جديدة مع الحفاظ على التوافق مع الإصدارات السابقة.

إصدار التصحيح

التعريف: يشير إلى إصلاحات الأخطاء المتوافقة مع الإصدارات السابقة أو تحسينات طفيفة.

التنسيق:

x.x.<Patch>
أمثلة: v1.0.0 -> v1.1.0: إصلاح خطأ بسيط في نقطة نهاية API.

سجل تغييرات API

سجل التغييرات هو سجل مفصّل للتغييرات, والتحسينات, وإصلاحات الأخطاء, والميزات الجديدة التي تم إدخالها في كل إصدار من البرامج أو API. يوفر الشفافية للمستخدمين والمطورين من خلال توثيق تأثير كل تحديث.

يتضمن الإدخال النموذجي في سجل التغييرات:

وصف: شرح موجز لما تم تغييره.

المكونات المتأثرة: وحدات أو نقاط نهاية أو ميزات محددة تأثرت بالتغيير.

مثال: تمت إضافة دعم لأمر API الجديد هذا <تسجيل النطاق>

سجل التغييرات

تتبّع كل تغيير يطرأ على Dynadot API.

9 أكتوبر, 2025
v2.0.0الميزات الجديدة والتغييرات الرئيسية بيئة الاختبار متاحة الآن تم إطلاق بيئة Sandbox رسميًا وأصبحت متاحة للاختبار الآمن والتحقق من التكامل. ترويسة X-Signature إلزامية للعمليات الحساسة لتعزيز الأمان، أصبحت ترويسة X-Signature مفروضة الآن على جميع أوامر API الحساسة. (اختياري) توثيق API قابل للقراءة آليًا نحن ندعم الآن وثائق API منظمة وقابلة للقراءة آليًا لسهولة التكامل مع الأدوات الآلية. الوصول إلى البحث مقيّد تم تقييد الوصول إلى بعض نقاط النهاية المتعلقة بالبحث لأسباب تتعلق بالأداء والتحكم في البيانات. تم تحسين القائمة البيضاء لعناوين IP لم يعد مطلوبًا من حساب الموزع إدخال IP واحد على الأقل لاستخدام API(RESTful API فقط) تحسينات في توثيق API محدد الإصدار المحدث على صفحة الوثائق الرئيسية لسهولة التنقل توحيد اصطلاحات حالة الأحرف في أسماء المعاملات تم توسيع الوثائق وإرشادات الاستخدام لنقطة النهاية bulk_search تمت إضافة ميزة لإخفاء/إظهار التنقل الجانبي
تم إدخال معلمات ترقيم الصفحات الإلزامية لتحسين كفاءة الاستجابة والاتساق. page (عدد صحيح، مطلوب) – يحدد فهرس الصفحة الحالية، بدءًا من 1. page_size (عدد صحيح، مطلوب) – يحدد عدد العناصر التي يتم إرجاعها في كل صفحة.get_listings