الواجهة البرمجية
أنشئ المستندات وأرسلها من نظامك مباشرة.
المطوّرون
من نظامك مباشرة: أنشئ المستند، وأرسله للتوقيع، واستلمه موقّعًا.
أنشئ المستندات وأرسلها من نظامك مباشرة.
يوقّع مستخدموك دون مغادرة تطبيقك.
يصلك إشعار فور تغيّر حالة المستند.
قدرات التوقيع في WQ3، متاحة داخل تطبيقاتك وأنظمتك.
اربط WQ3 بأنظمة ERP والموارد البشرية وإدارة العملاء والتخزين، أو اطلب تكاملًا مخصّصًا.
اطلب مفاتيح API من فريقنا.
أنشئ مستندًا وأضف موقّعين وأرسله.
اشترك في Webhooks لتعرف حالة كل توقيع فورًا.
قبل بدء التنفيذ، حدّد مستوى التوقيع المناسب لكل طرف في مسار العمل. تتيح وقع ثلاثة مستويات فقط: التوقيع الإلكتروني، والتوقيع عن بُعد، والتوقيع بالتوكن، مع إمكانية اختيار مستوى مختلف لكل موقّع في المستند نفسه. لذلك، صمّم قواعد التطبيق حول متطلبات كل موقّع، بدلًا من افتراض أن جميع الأطراف يحتاجون إلى المستوى نفسه.
تعامل مع التحقق من الحساب عبر eKYC بوصفه قرارًا مستقلًا؛ فهو إضافة للتحقق من الهوية يمكن اشتراطها مع أي مستوى، وليس مستوى توقيع رابعًا. التوقيع الإلكتروني مناسب للاتفاقات اليومية، بينما يناسب التوقيع عن بُعد أو بالتوكن العقود الرسمية أو مرتفعة القيمة. راجع متطلبات العقود مع الفريق القانوني قبل تحويل هذه الاختيارات إلى إعدادات افتراضية.
تُقفل المستندات في وقع بمجرد إرسالها، لذا ينبغي أن يتضمن تطبيقك خطوة مراجعة نهائية قبل بدء التوقيع. اطلب من المستخدم التأكد من نسخة المستند، والأطراف المطلوبة، ومستوى التوقيع لكل طرف. يساعد ذلك على فصل مرحلة إعداد المحتوى عن مرحلة التوقيع، ويحدّ من الالتباس حول النسخة المطلوب اعتمادها.
راعِ في تصميم تجربة الاستخدام أن لكل موقّع دعوة خاصة ورابطًا لا يعرض إلا ما يخصه. تجنّب وضع روابط الموقّعين في شاشات مشتركة أو رسائل تشخيص متاحة على نطاق واسع. وعند تضمين التوقيع داخل تطبيقك، ميّز بوضوح بين صلاحية إدارة سير العمل وصلاحية الاطلاع على مستندات الموقّع، بدلًا من اعتبار وجود المستخدم داخل التطبيق إذنًا كافيًا للوصول.
خطّط لما ينبغي أن يفعله تطبيقك عند وصول تحديث للحالة، وليس فقط لكيفية استقبال الإشعار. حدّد سجل العمل الداخلي المرتبط بعملية التوقيع، والمعلومات التي يحتاج المستخدم إلى رؤيتها، والإجراءات التي يجب تأجيلها حتى اكتمال التوقيع. لا ينبغي أن تعني حالة «تم الإرسال» في واجهتك أن الاتفاق أصبح مكتملًا.
اختبر أيضًا طريقة تعامل تطبيقك مع تأخر المعالجة أو انقطاعها، وكيفية منع تنفيذ الإجراء الداخلي نفسه مرتين إذا أُعيد تشغيل المعالجة. هذه اعتبارات لتصميم تطبيقك، وليست وصفًا لضمانات تسليم الأحداث في وقع. قبل الإطلاق، تأكّد مع الفريق من تفاصيل حمولة الأحداث، وآلية المصادقة، وسياسة إعادة المحاولة، وسلوك الأخطاء، بدلًا من استنتاجها من الوصف العام للصفحة.
صمّم آلية حفظ النتائج بحيث تشمل المستند النهائي وأدلة إتمامه، لا مجرد حالة تشير إلى انتهاء العملية. يصاحب كل مستند مكتمل سجل تدقيق وشهادة إتمام، ما يدعم المراجعة الداخلية وحفظ السجلات. اربط هذه المواد بسجل العمل المناسب، وحدّد من يحتاج إلى الاطلاع عليها في تطبيقك.
للمراجعة اللاحقة، تتوفر صفحة تحقق عامة دون حساب، ويمكن الوصول إليها باستخدام رمز QR والمرجع المرتبطين بالعقد. تعتمد مقارنة سلامة الملف على بصمة SHA-256؛ لذا احتفظ بالملف النهائي الأصلي بدلًا من الاكتفاء بنسخة معدّلة منه. تتوافق وقع مع قانون التوقيع الإلكتروني المصري رقم 15 لسنة 2004، لكن الأثر القانوني يظل مرتبطًا باستيفاء الشروط المعمول بها، وليس باستخدام واجهة برمجة التطبيقات وحدها.
REST API
أنشئ المستند، أضف الموقّعين، وتابع الأحداث من داخل تطبيقك.
POST /v1/documents
{
"name": "contract.pdf",
"signers": [
{ "email": "sara@example.com" }
]
}أنشئ حسابك على تطبيق WQ3، أو تحدث معنا عن متطلبات مؤسستك.
لا. يمكن اختيار مستوى مختلف لكل موقّع في المستند نفسه؛ لذا اجعل قواعد تطبيقك تراعي متطلبات كل طرف.
لا. هو إضافة للتحقق من هوية صاحب الحساب، ويمكن اشتراط حساب متحقق منه مع أي مستوى من مستويات التوقيع الثلاثة.
قبل الإرسال، لأن المستندات تُقفل بمجرد إرسالها. أضف خطوة تأكيد نهائية قبل بدء مسار التوقيع.
لا. تتيح صفحة التحقق العامة التأكد من أصالة العقد دون حساب، ويظهر رمز QR في الملف النهائي وشهادة الإتمام.
اطلب تفاصيل المصادقة، وحقول الطلبات، وحمولات الأحداث، وسياسة إعادة المحاولة، ومعالجة الأخطاء؛ فالصفحة الحالية لا تحدّد هذه التفاصيل.