Nhận SMS OTP tự động qua API: cách hoạt động và khi nào cần
Ai làm QA hoặc automation chắc từng gặp bài toán này: cần test flow đăng ký có xác minh SMS, mà mỗi lần chạy test lại phải có số điện thoại mới. Dùng số cá nhân thì được vài lần là hết cửa, mua SIM vật lý thì vừa đắt vừa không scale được khi cần chạy song song.
Số ảo giải quyết thế nào
Dịch vụ số ảo cho thuê số điện thoại theo phiên: bạn chọn quốc gia và ứng dụng đích, hệ thống cấp một số, SMS gửi đến số đó được đọc qua dashboard hoặc API. Số thường dùng một lần cho một dịch vụ, xong phiên thì trả lại pool.
Flow cơ bản qua API thường gồm bốn bước: request số mới cho service cần test, nhận số về, đưa số vào form đăng ký, rồi poll endpoint để lấy nội dung SMS chứa mã. Nhiều nhà cung cấp có thêm webhook để đỡ phải poll.
Ví dụ pseudo-flow:
GET /api/getNumber?service=telegram&country=vn→ trả về id phiên + số điện thoại- Điền số vào app đang test
GET /api/getStatus?id=...→ poll đến khi có mã (hoặc nhận webhook)- Xác minh xong → phiên đóng, tiền chỉ trừ khi mã thực sự về
Điểm đáng chú ý khi chọn nhà cung cấp cho mục đích kỹ thuật: độ trễ nhận SMS (ảnh hưởng trực tiếp thời gian chạy test), tỷ lệ số "sạch" chưa bị dịch vụ đích chặn, chính sách hoàn tiền khi SMS không về, và giới hạn rate của API. Chẳng hạn HeroSMS hỗ trợ 180+ quốc gia, hoàn tiền tự động nếu không có mã trong 20 phút - với pipeline CI/CD thì cơ chế auto-refund này tiết kiệm kha khá công xử lý lỗi.
Vài lưu ý khi tích hợp
Timeout nên đặt thoáng: SMS quốc tế có thể mất 30-120 giây. Retry logic nên phân biệt "chưa có mã" với "số bị dịch vụ đích từ chối" - trường hợp hai thì xin số mới nhanh hơn là chờ. Và log lại tỷ lệ thành công theo quốc gia: cùng một dịch vụ nhưng số của nước khác nhau cho kết quả khác hẳn nhau.
Cuối cùng, ranh giới sử dụng: số ảo hợp lệ cho testing, tách biệt môi trường, bảo vệ số cá nhân. Dùng để tạo tài khoản hàng loạt spam người khác thì vừa vi phạm ToS các nền tảng vừa làm bẩn pool số chung. Dùng đúng việc thì công cụ bền, mình cũng đỡ đau đầu.
All rights reserved
