مشتری پرداخت کرده، اما نمی داند سفارش ثبت شده است. کاربر دیگری منتظر کد ورود مانده و دوباره روی دکمه ارسال می زند. API ارسال پیامک زمانی این ارتباط را خودکار می کند که رویدادهای نرم افزار به ارسال پیام مناسب و پیگیری نتیجه متصل شوند.
برای شروع، یک سناریو مثل تأیید سفارش را انتخاب کنید. سپس مشخص کنید پیام چه زمانی ارسال شود، چه اطلاعاتی داشته باشد و اگر ارسال ناموفق بود، نرم افزار چه کاری انجام دهد.

چه پیامک هایی را می توان در نرم افزار خودکار کرد
پیش از نوشتن کد، مشخص کنید کدام رویداد محصول به اطلاع رسانی نیاز دارد.
| کاربرد | رویداد آغازگر | محتوای پیام | کنترل ضروری |
| ورود با کد یکبارمصرف | درخواست ورود کاربر | کد و مدت اعتبار | محدودیت درخواست و انقضا |
| تأیید سفارش | ثبت قطعی سفارش | شماره سفارش و وضعیت | جلوگیری از ارسال تکراری |
| اعلان پرداخت | تأیید پرداخت در سرور | مبلغ و شناسه پیگیری | بررسی نتیجه تراکنش |
| یادآوری نوبت | رسیدن زمان یادآوری | تاریخ و ساعت مراجعه | بررسی لغو یا جابه جایی نوبت |
| تمدید اشتراک | نزدیک شدن پایان اعتبار | تاریخ انقضا و مسیر تمدید | توقف پیام پس از تمدید |
| اطلاع رسانی پشتیبانی | ثبت پاسخ جدید | شماره تیکت و مسیر مشاهده | ارسال به صاحب تیکت |
قاعده اجرایی: پیامک را به تغییر معنادار وضعیت وصل کنید. باز شدن صفحه سفارش یا تازه سازی مرورگر، دلیل مناسبی برای ارسال دوباره تأیید خرید نیست.
API ارسال پیامک چگونه کار می کند
API پیامک رابطی است که نرم افزار از طریق آن، درخواست ارسال را به سامانه پیامکی می فرستد. درخواست معمولاً شامل اطلاعات احراز دسترسی، شماره گیرنده و متن پیام یا شناسه قالب و پارامترهای آن است. جزئیات هر سرویس را باید از مستندات همان ارائه دهنده برداشت کنید.
برای مثال، بعد از تأیید پرداخت، بک اند فروشگاه شماره سفارش را در قالب پیام قرار می دهد و درخواست ارسال را ثبت می کند. پاسخ سرویس نیز طبق مستندات بررسی و شناسه پیام برای پیگیری ذخیره می شود.
پذیرش درخواست با تحویل پیامک تفاوت دارد. ممکن است درخواست پذیرفته شده باشد، اما پیام هنوز در صف ارسال باشد یا بعداً تحویل نشود. بنابراین موفقیت اولیه API را معادل رسیدن پیام به مشتری در نظر نگیرید.
برای هر پیامک یک سناریوی مشخص تعریف کنید
ورود با کد یکبارمصرف
کاربر شماره موبایل را وارد می کند. بک اند درخواست را بررسی می کند، کد را می سازد و از طریق وب سرویس پیامکی می فرستد. پس از ورود کد، اعتبار آن در سرور بررسی می شود.
اگر خودتان کد را مدیریت می کنید، آن را با مولد تصادفی امن بسازید. کد باید زمان انقضا و مصرف یک باره داشته باشد. تعداد تلاش برای وارد کردن کد و تعداد درخواست ارسال را نیز محدود کنید. کد ورود و کلید API نباید وارد لاگ شوند.
برای حساب های حساس، احراز هویت را فقط به پیامک وابسته نکنید. خطرهایی مانند تصاحب شماره و فیشینگ باید در انتخاب روش ورود لحاظ شوند.
اعلان سفارش و پرداخت
پیام تأیید پرداخت را پس از بررسی نتیجه در بک اند ارسال کنید. بازگشت کاربر از درگاه یا نمایش صفحه موفقیت به تنهایی کافی نیست.
مثلاً پیام «سفارش شما پرداخت شد» باید بعد از تأیید تراکنش و ثبت وضعیت مربوط ارسال شود. اگر سفارش بعداً به مرحله ارسال رسید، پیام جداگانه ای با کد رهگیری بفرستید. هر پیام باید اطلاعات تازه ای به مشتری بدهد.
یادآوری نوبت و تمدید اشتراک
برای این پیام ها یک کار زمان بندی شده تعریف کنید. درست قبل از ارسال، وضعیت فعلی را دوباره بخوانید؛ شاید نوبت لغو شده یا اشتراک تمدید شده باشد.
در نرم افزار نوبت دهی، ارسال یادآوری برای رزرو لغوشده فقط یک خطای فنی نیست؛ مشتری را هم سردرگم می کند. شرط ارسال باید هم زمان یادآوری و هم معتبر بودن نوبت را بررسی کند.
اتصال نرم افزار به وب سرویس پیامکی را در شش مرحله انجام دهید
مرحله اول اطلاعات اتصال را آماده کنید
از مستندات سرویس، آدرس درخواست، روش احراز دسترسی، ساختار پاسخ، محدودیت نرخ و روش پیگیری وضعیت را استخراج کنید. خط فرستنده یا قالب موردنیاز را نیز پیش از تست آماده کنید.
کلید API را در بک اند نگه دارید. فرانت اند باید درخواست را به سرور خودتان بفرستد و سرور با سامانه پیامکی ارتباط بگیرد. قرار دادن کلید در کد مرورگر، امکان استفاده از اعتبار حساب را در اختیار دیگران می گذارد.
مرحله دوم رویداد و گیرنده را مشخص کنید
برای سناریوی تأیید سفارش، رویدادی مانند OrderConfirmed تعریف کنید. شماره گیرنده را از اطلاعات معتبر سفارش بردارید و قالب شماره را با مستندات سرویس تطبیق دهید.
همراه رویداد، شناسه سفارش، نوع پیام و زمان ایجاد را نگه دارید تا ارتباط پیام با عملیات اصلی قابل پیگیری باشد.
مرحله سوم ارسال را از درخواست اصلی جدا کنید
برای اعلان سفارش، رکورد ارسال را ذخیره کنید و پردازش آن را به یک Worker یا کار پس زمینه بسپارید. این کار باعث می شود کندی سرویس پیامکی، پاسخ ثبت سفارش را معطل نکند.
برای جلوگیری از جا افتادن اعلان، می توانید تغییر وضعیت سفارش و رکورد پیام را در یک تراکنش دیتابیس ثبت کنید. پردازش پس زمینه سپس رکوردهای آماده را ارسال می کند. این کاربرد الگوی Outbox است؛ ثبت رویداد را قابل اتکا می کند، اما تضمین تحویل پیامک به گوشی نیست.
برای OTP نیز صف و اولویت را طوری تنظیم کنید که کد ورود پشت ارسال های انبوه منتظر نماند. قبل از ارسال، اعتبار زمانی کد را بررسی کنید.
مرحله چهارم درخواست ارسال را بسازید
در ارسال متنی، گیرنده و متن را طبق ساختار سرویس بفرستید. در ارسال قالبی یا پترن، شناسه قالب و پارامترهای موردنیاز را تکمیل کنید. نام و ترتیب پارامترها باید با قالب ثبت شده هماهنگ باشد.
مثلاً قالب تأیید خرید ممکن است به نام مشتری و شماره سفارش نیاز داشته باشد. اگر شماره سفارش خالی است، درخواست را ارسال نکنید؛ پیام ناقص را نمی توان با یک پاسخ موفق API اصلاح کرد.
پیش از اتصال به رویداد واقعی، همین درخواست را با ابزار تست API و یک شماره آزمایشی اجرا کنید. متن دریافتی و شناسه برگشتی را بررسی کنید و سپس ارسال را وارد جریان نرم افزار کنید.
مرحله پنجم نتیجه را ذخیره کنید
شناسه پیام، وضعیت اولیه، زمان درخواست و ارتباط آن با سفارش را در دیتابیس نگه دارید. برای پیگیری تحویل، از وب هوک یا استعلام وضعیت استفاده کنید؛ انتخاب روش به امکانات سرویس بستگی دارد.
اگر وب هوک دارید، اصالت درخواست را طبق مستندات بررسی کنید. دریافت چندباره یک گزارش نباید باعث ثبت چندباره عملیات شود. اگر استعلام می زنید، فاصله درخواست ها را با محدودیت نرخ سرویس هماهنگ کنید.
وضعیت های سرویس را به وضعیت های داخلی مانند «در انتظار»، «تحویل شده» و «ناموفق» نگاشت کنید.

مرحله ششم ارسال تکراری را کنترل کنید
برای هر اعلان، یک کلید یکتا مانند order-4582-confirmed بسازید. روی این کلید محدودیت یکتا قرار دهید تا دو پردازش هم زمان نتوانند برای یک رویداد، دو رکورد ارسال ایجاد کنند.
اگر ارائه دهنده از Idempotency Key پشتیبانی می کند، مطابق مستندات از آن استفاده کنید. کنترل تکرار در دیتابیس خودتان ضروری است، اما به تنهایی ارسال دقیقاً یک باره را در تمام خطاهای شبکه تضمین نمی کند.

هنگام خطای API چه کاری انجام دهید
همه خطاها را با «ارسال مجدد» پاسخ ندهید. شماره نامعتبر با تکرار درخواست معتبر نمی شود و کلید اشتباه هم به فرصت دوباره نیاز ندارد.
| وضعیت | اقدام نرم افزار |
| شماره یا پارامتر نامعتبر | توقف و اصلاح داده |
| خطای احراز دسترسی | بررسی کلید و مجوزها |
| محدودیت نرخ | کاهش سرعت و رعایت زمان اعلام شده سرویس |
| خطای موقت سرویس | تلاش محدود با فاصله افزایشی طبق مستندات |
| قطع ارتباط با نتیجه نامشخص | بررسی پذیرش درخواست پیش از ارسال دوباره |
| تحویل ناموفق | بررسی علت و اجرای سیاست اطلاع رسانی جایگزین |
Timeout الزاماً به معنی ارسال نشدن نیست. ممکن است سرویس درخواست را گرفته باشد، اما پاسخ به نرم افزار نرسیده باشد. ارسال فوری همان پیام می تواند دو پیامک ایجاد کند. در صورت امکان، ابتدا با شناسه درخواست یا ابزار پیگیری سرویس، نتیجه را بررسی کنید.
برای تلاش مجدد سقف تعداد و مهلت تعیین کنید. یادآوری نوبت گذشته یا کد ورود منقضی شده را از چرخه ارسال خارج کنید.
متن پیامک خودکار چه اطلاعاتی داشته باشد
پیام باید نام سرویس، اتفاق رخ داده و اقدام بعدی را روشن کند. عبارت «عملیات با موفقیت انجام شد» برای مشتری توضیح نمی دهد دقیقاً چه اتفاقی افتاده است.
نمونه های زیر را با اطلاعات محصول خودتان جایگزین کنید:
تأیید سفارش: «فروشگاه آوا؛ پرداخت سفارش ۴۵۸۲ تأیید شد. وضعیت آماده سازی را در حساب کاربری ببینید.»
یادآوری نوبت: «کلینیک آوا؛ نوبت شما فردا ساعت ۱۶ است. برای تغییر زمان با پذیرش تماس بگیرید.»
کد ورود: «کد ورود آوا: ۷۳۱۹۴۲. اعتبار: ۲ دقیقه. این کد را در اختیار دیگران نگذارید.»
مدت اعتبار نوشته شده باید با تنظیمات واقعی بک اند یکسان باشد. اطلاعات حساس مانند رمز ثابت یا جزئیات خصوصی پرونده را در متن اعلان قرار ندهید.
پیش از فعال سازی چه چیزهایی را تست کنید
سناریوی عادی فقط بخشی از تست است. این حالت ها را نیز اجرا کنید:
- ثبت موفق سفارش و دریافت یک پیام مرتبط.
- اجرای دوباره همان رویداد و کنترل رکورد تکراری.
- شماره نامعتبر و ثبت خطای قابل پیگیری.
- قطع پاسخ سرویس و جلوگیری از ارسال مجدد بدون بررسی.
- لغو نوبت پیش از زمان یادآوری و توقف پیام.
- تلاش برای استفاده دوباره از OTP مصرف شده.
هشدار خطاهای پیوسته و کاهش اعتبار را تنظیم کنید. پشتیبانی باید بتواند با شماره سفارش، وضعیت پیام را پیدا کند.
سوالات متداول
آیا API ارسال پیامک فقط برای کد ورود است
خیر. API ارسال پیامک برای تأیید سفارش، اعلان پرداخت، یادآوری نوبت، تمدید اشتراک و اطلاع رسانی پشتیبانی نیز کاربرد دارد. نرم افزار با وقوع رویداد مشخص، درخواست ارسال پیام مرتبط را ثبت می کند.
آیا پاسخ موفق API به معنی تحویل پیامک است
خیر. پاسخ موفق می تواند فقط پذیرش درخواست را نشان دهد. برای بررسی تحویل، باید وضعیت پیام را با شناسه دریافتی و روش پیگیری ارائه دهنده بررسی کنید.
چگونه از ارسال پیامک تکراری جلوگیری کنیم
برای هر رویداد کلید یکتا بسازید و پردازش هم زمان را کنترل کنید. در خطاهای شبکه نیز پیش از تکرار ارسال، وضعیت پذیرش درخواست را بررسی کنید. در صورت پشتیبانی سرویس، از Idempotency Key استفاده کنید.
آیا اتصال API به هر زبان برنامه نویسی ممکن است
اگر سرویس رابط HTTP ارائه کند، می توانید از C#، PHP، Python یا JavaScript در بک اند استفاده کنید. SDK الزامی نیست؛ درخواست باید با مستندات سرویس سازگار باشد.
خودکارسازی پیامک را با یک سناریو شروع کنید
ابتدا تأیید سفارش یا یادآوری نوبت را پیاده سازی کنید. وقتی ثبت رویداد، ارسال، کنترل تکرار و پیگیری وضعیت درست کار کرد، سناریوهای دیگر را اضافه کنید. برای آشنایی با امکانات وب سرویس پیامکی پیام رسان، اینجا را ببینید و اطلاعات اتصال موردنیاز پروژه تان را بررسی کنید.