تحديث

POST https://api.pushwoosh.com/messaging/v2/update

يستبدل رسالة تم إنشاؤها مسبقًا، محددة بواسطة message_code الخاص بها، بتعريف جديد. الاستبدال هو استبدال كامل، وليس تصحيحًا: يتم تطبيق التعريف الجديد تمامًا كما تم إرساله، ولا يتغير message_code.

التحديث متاح فقط عندما تكون الرسالة لا تزال معلقة — أي مجدولة للإرسال في المستقبل ولم يتم التقاطها بعد للمعالجة أو التسليم.

هام

• حقل request هو تعريف Notify كامل. الحقول التي تحذفها لا يتم نقلها من الرسالة الأصلية — بل يتم إعادة تعيينها. أرسل الرسالة الكاملة التي تريدها، وليس فقط الأجزاء التي تم تغييرها.

• إذا كانت الرسالة قيد المعالجة بالفعل، أو تم تسليمها، أو تم إلغاؤها، أو تم حذفها، فإن واجهة برمجة التطبيقات (API) تُرجع 400. هذا الاستدعاء ليس متطابقًا. تحقق من حالة الرسالة قبل التحديث.

للتحقق مما إذا كانت الرسالة لا تزال في حالة قابلة للتحديث، انظر التحقق من حالة الرسالة.

الطلب

قم بالمصادقة باستخدام رمز Server API token الخاص بك في ترويسة Authorization: Token <API_TOKEN>.

الحقل	النوع	مطلوب	الوصف
message_code	string	نعم	رمز الرسالة (Message code) للرسالة التي سيتم تحديثها، كما تم إرجاعه بواسطة Notify في result.message_code.
request	object	نعم	التعريف الجديد الكامل للرسالة. له نفس شكل نص طلب Notify — كائن segment أو transactional. يتم التحقق من صحته تمامًا مثل Notify.

مثال على الطلب

إعادة جدولة رسالة segment وتغيير محتواها:

curl -X POST https://api.pushwoosh.com/messaging/v2/update \
  -H "Authorization: Token YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "message_code": "XXXX-XXXXXXXX-XXXXXXXX",
    "request": {
      "segment": {
        "application": "XXXXX-XXXXX",
        "platforms": ["IOS", "ANDROID"],
        "code": "active_users",
        "payload": {
          "content": {
            "localized_content": {
              "en": {
                "ios":     { "body": "Updated message" },
                "android": { "body": "Updated message" }
              }
            }
          }
        },
        "schedule": { "at": "2026-05-02T12:00:00Z" },
        "message_type": "MESSAGE_TYPE_MARKETING"
      }
    }
  }'

الاستجابة

عند النجاح، تُرجع HTTP 200 مع نتيجة الرسالة المحدثة. يبقى message_code دون تغيير.

{
  "result": {
    "message_code": "XXXX-XXXXXXXX-XXXXXXXX",
    "unknown_identifiers": []
  }
}

• message_code (string): نفس الرمز الذي تم تمريره في الطلب.
• unknown_identifiers (array of string): المعرفات في التعريف الجديد التي لم يتم العثور عليها، عند الاقتضاء (انظر Notify).

الأخطاء

تستخدم الأخطاء غلاف الخطأ القياسي لـ gRPC-Gateway: { "code": ..., "message": ..., "details": [...] }.

حالة HTTP	الشرط
400	message_code مفقود.
400	تعريف request الجديد مفقود أو غير صالح (يتم التحقق من صحته تمامًا مثل Notify).
400	الرسالة ليست في حالة قابلة للتحديث (لم تعد pending).
403	الرسالة تنتمي إلى حساب آخر.
404	لا توجد رسالة لـ message_code المحدد.
500	حدث خطأ داخلي أثناء تحميل الرسالة أو تطبيق التحديث. أعد محاولة الطلب.

مثال

تحديث رسالة لم تعد موجودة يُرجع HTTP 404:

{
  "code": 5,
  "message": "message not found",
  "details": []
}

التحقق من حالة الرسالة

قبل التحديث، يمكنك التحقق مما إذا كانت الرسالة لا تزال في حالة قابلة للتحديث. بالإضافة إلى قراءة عمود الحالة (Status) في جدول الرسائل في لوحة التحكم (الحملات → رسائل لمرة واحدة (Campaigns → One-time messages))، يمكنك الاستعلام عن الحالة برمجيًا باستخدام messages:list:

• مرر message_code في مصفوفة filters.messages_codes (بجانب filters.application المطلوب).
• اقرأ حقل status للإدخال المطابق في items[].

ملاحظة

messages:list هو جزء من Statistics API ويستخدم ترويسة مصادقة مختلفة عن هذه النقطة النهائية: Authorization: Api <Server Key>.

مواضيع ذات صلة

Notify

Cancel

إحصائيات الرسائل

نظرة عامة على Messaging API v2

الترحيل من v1