أرسل رسائل SMS و WhatsApp بشكل أسرع باستخدام Sent.dm API

الخلاصة / إجابة سريعة

توفر لك واجهة برمجة تطبيقات Sent.dm نقطة تكامل واحدة للمراسلة التجارية عبر الرسائل القصيرة (SMS) وواتساب. إذا قمت بإقران Sent مع Apidog، يمكنك تخزين بيانات الاعتماد الخاصة بك في بيئات، واختبار الطلبات دون كتابة نصوص مؤقتة، والتحقق من صحة حمولات الويب هوك، وتوثيق سير عمل المراسلة الخاص بك في مكان واحد.

مقدمة

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

وهذا بالضبط ما يجعل Sent.dm مثيرة للاهتمام. تضع Sent نفسها كواجهة برمجة تطبيقات موحدة للمراسلة عبر الرسائل القصيرة والقنوات المستندة إلى التطبيقات مثل واتساب، مع معالجة منطق التوجيه والتسليم خلف واجهة واحدة موجهة للمطورين. بناءً على وثائق Sent العامة التي تمت مراجعتها في 26 مارس 2026، تتضمن المنصة التحقق من الحساب، وإعداد القناة، والإرسال القائم على القوالب، وجهات الاتصال، وأحداث الويب هوك، ومساحة عمل لوحة التحكم للاختبار.

ما الذي تحله واجهة برمجة تطبيقات Sent.dm

تم تصميم Sent.dm للفرق التي ترغب في الوصول إلى المستخدمين على أكثر من قناة مراسلة واحدة دون الحاجة إلى الحفاظ على تكاملات منفصلة لكل مزود. بدلاً من ربط واجهات برمجة تطبيقات الرسائل القصيرة، وإعداد واتساب، وتنسيقات حمولات خاصة بالقناة، ومراقبة التسليم بنفسك، تقوم Sent بتجريد هذا التعقيد في منصة واحدة.

من الوثائق الرسمية، قصة المنتج واضحة ومباشرة:

• عنوان URL أساسي واحد لواجهة برمجة التطبيقات لسير عمل المراسلة
• مصادقة قائمة على الرأس باستخدام x-api-key
• نموذج هوية المرسل باستخدام x-sender-id
• المراسلة الصادرة المعتمدة على القوالب
• إدارة جهات الاتصال والجماهير
• أحداث الويب هوك للتسليم والقوالب
• مفاهيم التوجيه الذكي والتجاوز في طبقة المنصة

هذا المزيج مهم لأن أنظمة المراسلة نادرًا ما تكون مجرد "إرسال نص والانتقال". أنت بحاجة أيضًا إلى:

• هيكل حمولة متناسق
• طريقة آمنة لإعادة استخدام القوالب
• تتبع الأحداث للرسائل التي تم تسليمها أو فشلت أو وضعت في قائمة الانتظار
• سير عمل للاختبار يحافظ على الأسرار بعيدًا عن كود الواجهة الأمامية
• وثائق يمكن لمطوريك وزملاء فريق ضمان الجودة استخدامها بالفعل

إليك التحدي الأكبر عمليًا:

Application -> Message API -> Channel Rules -> Delivery Events -> Retry / Status Logic

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

كيف تعمل واجهة برمجة تطبيقات Sent.dm

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

بالنسبة للمطورين، الأجزاء الأكثر أهمية هي تسلسل الإعداد ونموذج بيانات الاعتماد.

1. إعداد الحساب والامتثال

يبدأ سير عمل البدء الرسمي بإنشاء الحساب، والتحقق من الهوية (KYC)، وإعداد العمل. هذا ليس عملًا منزليًا اختياريًا. منتجات المراسلة تلامس قواعد الامتثال، وسمعة المرسل، والقيود الإقليمية، لذلك تجعل Sent التحقق من الحساب جزءًا من مسار الإعداد.

2. إعداد القناة

ترشدك وثائق Sent خلال اختيار رقم هاتف وربط واتساب للأعمال. توصي الوثائق باستخدام نفس الرقم للرسائل القصيرة وواتساب لكي تبقى هوية علامتك التجارية متناسقة عبر القنوات.

3. القوالب

القوالب جزء أساسي من سير العمل. في دليل البدء، تطلب منك Sent إنشاء قالب قبل إرسال طلب واجهة برمجة التطبيقات الأول. هذه إشارة جيدة إلى أن المراسلة المستندة إلى القوالب ليست حالة هامشية هنا. إنها جزء من المسار الافتراضي.

4. بيانات اعتماد واجهة برمجة التطبيقات

تعرض الوثائق بيانات اعتماد اثنتين:

x-sender-id: YOUR_SENDER_ID
x-api-key: YOUR_API_KEY

يسلط مرجع واجهة برمجة التطبيقات v3 الضوء على x-api-key كعنوان مصادقة مطلوب. تتضمن أمثلة البدء أيضًا x-sender-id لطلبات الرسائل. عند تنفيذ هذا في الإنتاج، تحقق من المتطلبات الدقيقة للرأس مقابل مساحة العمل الحالية وإصدار نقطة النهاية في لوحة تحكم Sent، لأن الوثائق تعرض كلاً من عرض مرجع v3 وأمثلة رسائل v2.

5. طلب الرسالة

يعرض دليل البدء طلبًا إلى:

POST https://api.sent.dm/v2/messages/phone

مع حمولة JSON بهذا الشكل:

{
 "phoneNumber": "RECIPIENT_PHONE_NUMBER",
 "templateId": "TEMPLATE_ID"
}

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

أرسل أول طلب واجهة برمجة تطبيقات Sent.dm

دعنا نبني الطلب الأول بطريقة سهلة الاختبار وسهلة الصيانة.

مثال cURL

curl -X POST "https://api.sent.dm/v2/messages/phone" \
 -H "x-sender-id: YOUR_SENDER_ID" \
 -H "x-api-key: YOUR_API_KEY" \
 -H "Content-Type: application/json" \
 -d '{
 "phoneNumber": "RECIPIENT_PHONE_NUMBER",
 "templateId": "TEMPLATE_ID"
 }'

مثال JavaScript

const response = await fetch("https://api.sent.dm/v2/messages/phone", {
 method: "POST",
 headers: {
 "x-sender-id": process.env.SENT_SENDER_ID,
 "x-api-key": process.env.SENT_API_KEY,
 "Content-Type": "application/json"
 },
 body: JSON.stringify({
 phoneNumber: process.env.TEST_PHONE_NUMBER,
 templateId: process.env.SENT_TEMPLATE_ID
 })
});

if (!response.ok) {
 throw new Error(`Sent request failed: ${response.status}`);
}

const data = await response.json();
console.log(data);

مثال Python

import os
import requests

response = requests.post(
 "https://api.sent.dm/v2/messages/phone",
 headers={
 "x-sender-id": os.environ["SENT_SENDER_ID"],
 "x-api-key": os.environ["SENT_API_KEY"],
 "Content-Type": "application/json",
 },
 json={
 "phoneNumber": os.environ["TEST_PHONE_NUMBER"],
 "templateId": os.environ["SENT_TEMPLATE_ID"],
 },
 timeout=30,
)

response.raise_for_status()
print(response.json())

وفقًا لوثائق البدء، يعيد الرد الناجح HTTP 200 و messageId. هذه الـ messageId هي القيمة التي تريد التقاطها في اختبارات Apidog، وسجلات التطبيق، وسير عمل الدعم، ومطابقة الويب هوك.

اختبر واجهة برمجة تطبيقات Sent.dm في Apidog

هنا يصبح Apidog أكثر من مجرد مشغل للطلبات. يصبح التعامل مع واجهات برمجة تطبيقات المراسلة أسهل عندما يكون الطلب والمتغيرات وتأكيدات الاختبار والوثائق وتسليم الفريق كلها موجودة معًا.

الخطوة 1: أنشئ بيئة Sent

في Apidog، أنشئ بيئة بمتغيرات مثل:

base_url = https://api.sent.dm
sender_id = YOUR_SENDER_ID
api_key = YOUR_API_KEY
template_id = YOUR_TEMPLATE_ID
test_phone = RECIPIENT_PHONE_NUMBER

يمنحك استخدام متغيرات البيئة ثلاث فوائد فورية:

1. تجنب إدخال أسرار الإنتاج يدويًا في الأمثلة.
2. يمكنك التبديل بين بيئات الاختبار المؤقتة، بيئات التجربة، والحسابات المباشرة بشكل أسرع.
3. يمكن لزملائك في الفريق إعادة استخدام نفس المجموعة بقيمهم الآمنة.

الخطوة 2: أنشئ الطلب مرة واحدة

أنشئ طلبًا جديدًا في Apidog:

- x-sender-id: {{sender_id}} - x-api-key: {{api_key}} - Content-Type: application/json

• الأسلوب: POST
• عنوان URL: {{base_url}}/v2/messages/phone
• العناوين:
• الجسم:

{
 "phoneNumber": "{{test_phone}}",
 "templateId": "{{template_id}}"
}

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

الخطوة 3: أضف التأكيدات

في Apidog، أضف اختبارات تتحقق من مسار النجاح.

أمثلة على الفحوصات:

pm.test("Status is 200", function () {
 pm.response.to.have.status(200);
});

pm.test("Response contains a messageId", function () {
 const json = pm.response.json();
 pm.expect(json.messageId).to.exist;
});

تساعدك هذه الفحوصات على اكتشاف الأخطاء الخفية بسرعة. إذا توقف الطلب عن إعادة معرف رسالة (message ID) بعد تغيير في واجهة برمجة التطبيقات، أو تدوير بيانات الاعتماد، أو مشكلة في القالب، فسترى ذلك على الفور.

الخطوة 4: حوّلها إلى سيناريو

يصبح Apidog أكثر فائدة عندما تنتقل من طلب واحد إلى سير عمل:

1. أرسل رسالة
2. خزّن messageId المُعاد
3. استعلم عن الحالة النهائية إذا كان إعدادك يكشف هذا التدفق
4. قارن أحداث الرسائل المستلمة عبر الويب هوكس

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

الخطوة 5: أضف أمثلة الويب هوك إلى نفس المجموعة

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

على سبيل المثال، يمكنك حفظ مثال حمولة ويب هوك وتوثيق الحقول مثل:

{
 "field": "message.status",
 "messageId": "msg_123",
 "status": "delivered",
 "channel": "whatsapp"
}

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

الخطوة 6: انشر الوثائق الداخلية

إذا كان فريقك يضم مهندسي الواجهة الخلفية، وضمان الجودة، والدعم، وأصحاب المصلحة في المنتج الذين يتعاملون مع نفس سير عمل المراسلة، فإن طبقة توثيق Apidog توفر الوقت. بدلاً من مشاركة مجموعة فضفاضة من مقتطفات cURL في الدردشة، يمكنك نشر مرجع داخلي نظيف يتضمن:

• العناوين المطلوبة
• أمثلة الحمولات
• استجابات الأخطاء
• أمثلة أحداث الويب هوك
• ملاحظات البيئة

هذا تسليم أقوى بكثير من "شغّل هذا السكريبت وأخبرني ماذا حدث".

تعامل مع القوالب وجهات الاتصال والويب هوكس بالطريقة الصحيحة

الحصول على استجابة 200 للطلب الأول هو مجرد البداية. يبدأ عمل الإنتاج الحقيقي بعد ذلك.

القوالب

يركز سير عمل إعداد Sent بشدة على القوالب، خاصة للمراسلات المتعلقة بواتساب. وهذا يعني أن تنفيذ واجهة برمجة التطبيقات الخاص بك يجب أن يتعامل مع القوالب كمحتوى ذي إصدارات، وليس مجرد معرفات يتم نسخها إلى ملف مرة واحدة وتُنسى.

نموذج عملي هو:

1. احتفظ بمعرفات القوالب في متغيرات البيئة أو التكوين
2. صنف كل قالب حسب الغرض، واللغة، وحالة الموافقة
3. افصل قوالب الاختبار عن قوالب الحملات المباشرة
4. وثق أي القوالب تتوافق مع أي مسارات للمستخدمين

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

جهات الاتصال

تُظهر وثائق Sent جهات الاتصال كمجال ميزة من الدرجة الأولى. حتى لو كان تطبيقك يخزن المستخدمين داخليًا بالفعل، فإن كائنات جهات الاتصال في منصة مراسلة مفيدة لعمليات على مستوى الجمهور، واستهداف القوالب، وسجل الاتصالات.

إذا قمت بإنشاء منطق مزامنة جهات الاتصال، فوثق هذه القواعد مبكرًا:

• أي نظام هو مصدر الحقيقة
• كيف يتم تطبيع أرقام الهواتف
• كيف يتم تخزين حالة الموافقة أو الاشتراك
• ماذا يحدث عندما تغير جهة اتصال القنوات

هذه ليست تفاصيل لتنظيفها لاحقًا. إنها تؤثر على قابلية التسليم والامتثال منذ البداية.

الويب هوكس

وثائق الويب هوك الخاصة بـ Sent هي أحد أهم أجزاء المنصة للاستخدام الإنتاجي الحقيقي. تصف الوثائق التحقق من توقيع HMAC-SHA256 مع عناوين تتضمن:

• x-webhook-signature
• x-webhook-id
• x-webhook-timestamp

تصف الوثائق أيضًا تنسيق التوقيع على أنه v1,{base64_signature} وتوصي بحماية إعادة التشغيل مع نافذة زمنية مدتها خمس دقائق.

هذا يمنحك قائمة مرجعية إنتاجية نظيفة:

1. اقرأ نص الطلب الخام
2. تحقق من التوقيع قبل التحليل
3. ارفض الطوابع الزمنية القديمة
4. عالج الأحداث بشكل متطابق
5. أقر بالاستلام بسرعة وانقل العمل الثقيل إلى مهام الخلفية

إليك مثال Express موجز:

import crypto from "crypto";
import express from "express";

const app = express();

app.post("/webhooks/sent", express.raw({ type: "*/*" }), (req, res) => {
 const signature = req.header("x-webhook-signature");
 const webhookId = req.header("x-webhook-id");
 const timestamp = req.header("x-webhook-timestamp");
 const secret = process.env.SENT_WEBHOOK_SECRET;
 const rawBody = req.body.toString("utf8");

 const signedContent = `${webhookId}.${timestamp}.${rawBody}`;
 const expected = crypto
 .createHmac("sha256", Buffer.from(secret.replace(/^whsec_/, ""), "base64"))
 .update(signedContent)
 .digest("base64");

 if (signature !== `v1,${expected}`) {
 return res.status(401).send("Unauthorized");
 }

 const event = JSON.parse(rawBody);
 console.log("Received webhook event:", event.field);

 return res.sendStatus(200);
});

استخدم Apidog لتخزين عينات حمولات الويب هوك وتوثيق الأحداث المتوقعة. هذا يسهل على فرق الواجهة الأمامية والواجهة الخلفية وضمان الجودة التوافق حول نفس دورة حياة الرسائل.

لماذا يتناسب Apidog مع سير العمل هذا

تمنحك Sent.dm طبقة المراسلة. يمنحك Apidog طبقة سير العمل حول طبقة المراسلة تلك.

إليك الفرق العملي:

إذا كان فريقك يقيم Sent للمراسلة التطبيقية، فإن Apidog يغطي الطبقة التي لا تحاول Sent أن تكونها: تصميم واجهة برمجة التطبيقات التعاوني، والاختبار، وتصحيح الأخطاء، وتخطيط النماذج (mock planning)، والتوثيق في مساحة عمل واحدة.

هذا مفيد في ثلاث حالات على الأقل:

• أنت تقوم بتدريب مطورين متعددين وتحتاج إلى مجموعة طلبات قابلة للمشاركة
• تريد من ضمان الجودة التحقق من صحة واجهات برمجة تطبيقات المراسلة دون كتابة نصوص مخصصة
• تحتاج إلى مكان قابل للتكرار لاختبار تغييرات الإصدارات، أو القوالب الجديدة، أو حمولات الويب هوك

قم بتنزيل Apidog مجانًا لاختبار طلبات Sent.dm، وتخزين بيئات المراسلة بأمان، وتحويل أول مكالمة ناجحة لواجهة برمجة التطبيقات إلى سير عمل فريق قابل لإعادة الاستخدام.

نصائح متقدمة وأخطاء شائعة

بمجرد أن يعمل التدفق الأساسي، تجعل هذه الممارسات التكامل أكثر موثوقية.

أفضل الممارسات

1. احتفظ ببيانات الاعتماد على جانب الخادم فقط. تحذر وثائق Sent صراحةً من كشف مفاتيح API في كود جانب العميل.
2. تتبع messageId في سجلات تطبيقك وأدوات الدعم.
3. افصل قوالب بيئة الاختبار وقوالب الإنتاج.
4. تحقق من كل ويب هوك قبل معالجته.
5. استخدم بيئات Apidog لعزل بيانات الاعتماد الحية عن بيانات الاعتماد الاختبارية.

الأخطاء الشائعة التي يجب تجنبها

1. معاملة استجابة 200 كنتيجة التسليم النهائية بدلاً من بداية دورة حياة الحدث.
2. ترميز معرفات القوالب بشكل ثابت في خدمات متعددة.
3. تجاهل إعداد هوية المرسل حتى وقت متأخر من الإطلاق.
4. نسيان تطبيع أرقام الهواتف بشكل متناسق.
5. الاختبار باستخدام بيانات اعتماد حقيقية في نصوص عشوائية لا يمكن لأي شخص آخر فحصها.

مؤشرات استكشاف الأخطاء وإصلاحها

إذا كان الطلب لا يعمل، تحقق من هذه النقاط بالترتيب:

1. هل x-api-key صالح ونشط؟
2. هل تتطابق نقطة النهاية التي تستدعيها مع الإصدار الموضح في مساحة عمل Sent الخاصة بك؟
3. هل x-sender-id مطلوب لمسار الطلب هذا؟
4. هل القالب معتمد ومتاح للقناة المختارة؟
5. هل ترسل إلى رقم هاتف بالتنسيق الصحيح؟

يساعد Apidog هنا لأنه يمكنك مقارنة طلب فاشل بطلب محفوظ معروف بأنه جيد في ثوانٍ.

بدائل ومقارنات Sent.dm

إذا كنت تقيّم Sent.dm، فمن المحتمل أنك تبحث أيضًا عن تكاملات مباشرة مع المزودين، أو منصات اتصالات أوسع، أو عميل API مألوف مثل Postman للاختبار اليومي. الفرق الرئيسي هو التحكم مقابل البساطة، وطبقة الاختبار لا تقل أهمية عن طبقة التسليم.

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

الخلاصة

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

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

الأسئلة الشائعة

ما هو استخدام واجهة برمجة تطبيقات Sent.dm؟

تُستخدم واجهة برمجة تطبيقات Sent.dm للمراسلة التجارية عبر قنوات مثل الرسائل القصيرة (SMS) وواتساب من خلال تكامل واحد. بناءً على الوثائق الرسمية، تدعم إعداد المرسل، والقوالب، وجهات الاتصال، ومعالجة الأحداث القائمة على الويب هوك.

هل تدعم Sent.dm واتساب والرسائل القصيرة في واجهة برمجة تطبيقات واحدة؟

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

ما هي العناوين التي أحتاجها لطلبات واجهة برمجة تطبيقات Sent.dm؟

تُظهر الوثائق العامة x-api-key كعنوان مصادقة أساسي، وتستخدم أمثلة رسائل البدء أيضًا x-sender-id. تحقق من الإصدار الدقيق لنقطة النهاية في حساب Sent الخاص بك قبل الإطلاق الإنتاجي لأن الوثائق تعرض كلاً من مراجع v3 و v2.

هل أحتاج إلى قوالب قبل إرسال الرسائل باستخدام Sent.dm؟

بالنسبة لسير عمل البدء، نعم. يرشدك دليل إعداد Sent خلال إنشاء قالب ثم إرسال الرسالة الأولى باستخدام templateId.

كيف يمكنني اختبار واجهة برمجة تطبيقات Sent.dm دون كتابة نصوص مخصصة؟

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

كيف يجب أن أؤمن ويب هوكس Sent.dm؟

تحقق من توقيع HMAC، وتحقق من صحة الطابع الزمني، وقم بمعالجة الأحداث بشكل متطابق. تصف وثائق Sent عناوين مثل x-webhook-signature، x-webhook-id، و x-webhook-timestamp للتحقق.

هل Sent.dm كافية بحد ذاتها لسير عمل فريق واجهة برمجة التطبيقات؟

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