sent có nghĩa là Meta đã chấp nhận tin nhắn, chứ không phải người nhận đã nhận được. Trên Instagram, việc chuyển tin cuối cùng do thiết lập Message requests của người nhận quyết định: nếu họ không cho phép nhận message request từ mọi người, Meta sẽ trả về phản hồi thành công rồi âm thầm loại bỏ tin nhắn, và điều này là vô hình ở mọi tầng API. Ngay cả một DM được kích hoạt từ bình luận đã chuyển thành công cũng đến dưới dạng một message request mà người nhận phải chấp nhận (trừ khi một cuộc trò chuyện đã tồn tại giữa hai tài khoản). Xem Automation DM đã Gửi nhưng Không được Chuyển để có giải thích đầy đủ.Cách hoạt động
Tạo một automation
POST /automations với các trigger và action mà bạn muốn. Automation được kích hoạt ngay lập tức.Người dùng cuối tương tác
Ayrshare khớp và điều phối
Kiểm tra những gì đã kích hoạt
GET /automations/:id/activity trả về nhật ký kiểm toán — mọi lần thử điều phối, kết quả của từng action, và bất kỳ lỗi nào.Trigger
Bạn có thể đính kèm tối đa 50 trigger cho một automation. Mỗi trigger là một discriminated union trên trườngtype; các trường dành riêng cho type nằm cùng cấp. Cột Nền tảng cho biết mỗi trigger khả dụng ở đâu; xem Trang Facebook để biết Facebook cần những gì.
Quy tắc evergreen với "all"
Đặt postId (hoặc storyId) thành chuỗi chữ thường theo nghĩa đen "all" để kích hoạt trên mọi bài đăng, reel, hoặc story trên tài khoản đã kết nối thay vì một nội dung cụ thể. Đây là điều bạn muốn cho một quy tắc cần tiếp tục hoạt động khi nội dung mới được xuất bản, mà không cần một lời gọi API cho mỗi bài đăng:
"all". Một biến thể như "ALL" hoặc " all" bị từ chối với một lỗi validation thay vì được lưu như một ID bài đăng sẽ không bao giờ khớp.
"all" không bao giờ mở rộng ra ngoài tài khoản đã kết nối — một quy tắc trên một profile không thể kích hoạt trên nội dung của profile khác. Giới hạn DM hàng ngày của bạn và các quy tắc gửi được neo vào tương tác áp dụng chính xác như với một quy tắc trên một bài đăng đơn lẻ.
storyId hoạt động giống như "all". Hãy ưu tiên "all" — nó nêu rõ ý định một cách tường minh, và việc bỏ qua sẽ bị loại bỏ trong một bản phát hành tương lai với thông báo trước trên Upcoming API Changes.Trang Facebook
Đặtplatform thành facebook để chạy một automation trên Trang Facebook được liên kết với profile. DM được gửi từ Trang thông qua Messenger.
- Trigger:
dm_keywordvàdm_reaction. Các trigger bình luận và story hiện chỉ dành cho Instagram, và một automation Facebook sử dụng một trong số đó sẽ bị từ chối với lỗi xác thực dữ liệu. - Messaging: profile cần kích hoạt Messaging cho Facebook, giống như khi gửi một DM Facebook bằng Messages API.
- Người nhận:
{{recipient_id}}là ID theo phạm vi Trang (PSID) của người dùng.{{recipient_username}}để trống, vì webhook của Messenger không bao gồm tên người dùng.
Action
Bạn có thể đính kèm tối đa 50 action cho một automation. Chúng chạy tuần tự; mỗi kết quả được ghi lại trên hàng activity.Cửa sổ dedup theo action
Mọi action — bất kể loại — cũng chấp nhận một trườngdedupWindowMinutes cấp cao nhất tùy chọn ghi đè cửa sổ dedup mặc định 7 ngày theo người nhận chỉ cho action đó.
- Đặt thành
0để vô hiệu hóa dedup hoàn toàn cho action đó (điển hình chofire_webhook/send_emailnơi người nhận mong đợi mọi sự kiện). - Giới hạn tối đa ở
525600(một năm).
Nội dung tin nhắn động
Theo mặc định,send_dm gửi cùng một message tới mọi người kích hoạt quy tắc. Các placeholder như {{recipient_username}} là phần duy nhất thay đổi theo từng người. Hãy đặt messageUrl trên action và máy chủ của chính bạn sẽ viết DM cho từng người: mỗi lần quy tắc khớp, chúng tôi hỏi endpoint của bạn cần nói gì, rồi gửi câu trả lời của nó dưới dạng DM.
Ví dụ. Quy tắc của bạn trả lời bất kỳ ai bình luận “LINK” trên một bài đăng, và messageUrl trỏ tới máy chủ của bạn. Khi Ava bình luận “LINK please!”:
- Chúng tôi
POSTthông tin chi tiết tớimessageUrlcủa bạn: ai đã bình luận ("recipientUsername": "ava"), họ đã viết gì, và bình luận nằm trên bài đăng nào. - Máy chủ của bạn viết một câu trả lời cho Ava, ví dụ kèm một liên kết theo dõi được tạo riêng cho cô ấy, và trả về
{ "message": "Hi ava, here's your link: https://example.com/r/12345" }. - Chúng tôi gửi văn bản đó tới Ava dưới dạng DM, đúng như bạn đã viết.
timeoutMs, trả về lỗi, hoặc trả về nội dung chúng tôi không thể sử dụng, chúng tôi sẽ gửi cho Ava message thông thường của action thay thế, để cô ấy vẫn nhận được phản hồi.
Thêm nó vào một action send_dm như sau:
messageUrl là nơi chúng tôi yêu cầu văn bản. message vẫn là bắt buộc và đóng vai trò phương án dự phòng: nó không bao giờ được gửi tới máy chủ của bạn, và chúng tôi gửi DM bằng nó bất cứ khi nào máy chủ của bạn không trả lời kịp thời, trả về lỗi, hoặc trả về nội dung chúng tôi không thể sử dụng (xem cảnh báo bên dưới). timeoutMs là tùy chọn (mặc định 3000, tối đa 5000).
Những gì chúng tôi gửi tới endpoint của bạn. Một yêu cầu POST với body JSON sau:
automations của bạn, theo cùng một cách: X-Authorization-Content-SHA256 là HMAC-SHA256 của body thô, và X-Authorization-Timestamp mang timeStamp của body. Mã xác minh bạn đang dùng cho các webhook của chúng tôi hoạt động mà không cần thay đổi. Nếu một secret đã được đăng ký nhưng chúng tôi không thể đọc nó tại thời điểm đó, chúng tôi không gửi callback mà không ký; thay vào đó chúng tôi gửi template message của bạn.
Nơi nó có thể trỏ tới. messageUrl phải là một địa chỉ HTTPS công khai. Một URL phân giải tới địa chỉ private, loopback, link-local hoặc cloud-metadata sẽ bị từ chối, và các chuyển hướng không được theo — một phản hồi 3xx được tính là thất bại. Trong cả hai trường hợp, template sẽ được gửi thay thế.
Những gì endpoint của bạn trả về. Trả về 200 với một body JSON, tối đa 16 KB, chứa một chuỗi message dài từ 1 đến 1000 ký tự:
{{placeholder}} không được áp dụng cho nó, nên một chuỗi {{ theo nghĩa đen trong văn bản bạn tạo ra sẽ đến tay người nhận đúng như đã viết.
timeoutMs mặc định là 3000. Giá trị tối đa là 5000: một giá trị lớn hơn sẽ bị từ chối với lỗi validation khi bạn tạo hoặc cập nhật automation. Nó bao trùm toàn bộ quá trình trao đổi, bao gồm cả việc đọc body phản hồi của bạn. Hãy tính đến nó: DM được gửi sau khi endpoint của bạn trả lời, nên một endpoint chậm sẽ làm chậm tin nhắn.
Kiểm tra lần kích hoạt đã đi theo nhánh nào trên GET /automations/:id/activity. Một mục send_dm trong actionResults[] mang messageSource khi văn bản DM đã được xác định, kể cả khi lần gửi sau đó thất bại. Nó không có mặt khi action dừng trước bước đó, ví dụ một DM skipped tới chính tài khoản của bạn hoặc một action deduplicated:
messageSource cho biết DM được tạo từ văn bản nào, chứ không cho biết nó đã được chuyển hay chưa. Hãy đọc status của mục để biết điều đó.
Bản thân một fallback không làm action thất bại: khi DM từ template được chuyển, mục là sent, với lý do callback không được sử dụng trên errorDetails. Nếu DM từ template sau đó cũng thất bại, mục là failed và errorDetails đưa ra lỗi gửi, theo sau là lý do của callback. Hãy theo dõi điều này: nếu không, một callback thất bại ở mọi lần kích hoạt trông giống hệt một callback đang hoạt động bình thường.
Hãy giữ cho message của bạn có thể tự gửi được. Nếu nó render ra rỗng cho một người nhận, ví dụ chỉ có {{recipient_username}} trên một trigger DM không mang theo tên người dùng, và văn bản callback của bạn không được sử dụng, sẽ không có DM nào được gửi và action là failed với lý do trên errorDetails.
Sự kiện webhook
Hai sự kiện được chuyển tới webhook actionautomations mà bạn đăng ký với POST /hook/webhook. Cả hai đều mang một trường type — hãy phân nhánh trên nó trước khi đọc bất cứ điều gì khác.
automation.completed tắt theo mặc định. Bật nó cho một automation bằng cách đặt "sendCompletedEvent": true trên action fire_webhook của automation đó. Nếu không, nó vẫn tắt, nên một receiver được xây dựng cho một payload mỗi lần kích hoạt vẫn tiếp tục nhận đúng một. automation.triggered không phải là bản ghi của mọi lần khớp: nó chỉ được gửi khi chính fire_webhook chạy, nên một lần khớp kết thúc rate_limited hoặc deduplicated chỉ tạo ra automation.completed. Không sự kiện nào được gửi cho một automation đã bị hủy kích hoạt hoặc bị xóa trước khi việc điều phối chạy.automation.triggered
activityId là hàng mà GET /automations/:id/activity trả về, nên bạn có thể join hai bên một cách chính xác thay vì khớp trên recipientId + triggerId + keyword — vốn mơ hồ khi nhiều người bình luận cùng một từ khóa cùng lúc. actionId là action fire_webhook đã gửi sự kiện, và khớp với actionResults[].actionId; nó giúp phân biệt hai action fire_webhook trên cùng một quy tắc.
Các trường mà một trigger không điền là null thay vì bị bỏ đi, nên hình dạng payload ổn định. recipientUsername là null với dm_keyword, dm_reaction và story_reply, vì payload của Meta không bao gồm nó. commentId chỉ được đặt cho comment_keyword và story_comment, postId chỉ cho comment_keyword, và storyId chỉ cho các story trigger. story_reply không có keyword. Với dm_keyword, commentText là văn bản DM; với dm_reaction, commentText và keyword đều là emoji của phản ứng.
automation.completed
Chỉ được gửi khi automation chọn tham gia trên action fire_webhook của nó:
status và mỗi actionResults[].status sử dụng cùng các giá trị với nhật ký activity — sent, failed, rate_limited, deduplicated, skipped, auth_error — nên trong trường hợp thông thường bạn biết một lần điều phối kết thúc thế nào mà không cần polling. Tuy nhiên, việc chuyển sự kiện này là best-effort: nếu tiến trình dừng giữa lúc ghi lại kết quả và xếp hàng sự kiện, nó không được gửi. Nhật ký activity là bản ghi chuẩn xác, nên nếu bạn cần mọi kết quả, hãy đối chiếu với GET /automations/:id/activity cho bất kỳ activityId nào chưa báo cáo một kết quả. Một kết quả send_dm cũng mang messageSource, giống như trên nhật ký activity: template, callback hoặc fallback, để bạn có thể phát hiện một messageUrl liên tục rơi vào fallback mà không cần polling. Khớp kết quả với các action bạn đã cấu hình bằng actionId, không phải theo vị trí — hai action cùng loại chỉ có thể phân biệt được theo cách đó. actionResults trống trong ba trường hợp, mỗi trường hợp có lý do trên errorDetails cấp cao nhất khi có: rate_limited (đã đạt đến giới hạn hàng ngày của bạn), deduplicated (mọi action đều nằm trong cửa sổ dedup của nó), và failed sau khi việc điều phối đã được thử lại số lần tối đa mà không hoàn tất. Trong trường hợp cuối cùng đó, một số action có thể đã chạy rồi, nên một DM có thể đã được gửi đi và automation.triggered có thể đã được gửi.
Việc chuyển webhook là at-least-once, nên cùng một sự kiện đôi khi có thể đến hai lần, và một lần điều phối được thử lại có thể gửi lại automation.triggered với một hookId mới. Đừng bao giờ deduplicate trên hookId. Hãy đặt khóa cho mỗi loại sự kiện riêng biệt, để việc xử lý sự kiện này không bao giờ chặn sự kiện kia: automation.completed trên activityId (mỗi activity có một kết quả), và automation.triggered trên activityId cộng với actionId (một cho mỗi action fire_webhook). Hai sự kiện được chuyển độc lập, nên automation.completed đôi khi có thể đến trước automation.triggered.
Nếu không có webhook nào được đăng ký
fire_webhook POST tới action automations được đăng ký trên profile, dự phòng về Primary Profile của bạn. Không có dự phòng sang một action khác như messages. Nếu cả hai đăng ký đều không tồn tại, automation.triggered không bị âm thầm loại bỏ: action được ghi trên hàng activity là failed, với lý do trong actionResults[].errorDetails. (automation.completed cũng không có nơi nào để đến, và không được ghi lại.) Trạng thái tổng thể của lần điều phối sau đó tuân theo thứ tự ưu tiên thông thường: auth_error nếu bất kỳ action nào gặp lỗi xác thực, nếu không thì sent nếu bất kỳ action nào được chấp nhận, nếu không thì failed. Do đó webhook bị thiếu chỉ được tính vào số liệu thất bại của automation khi không có gì khác trên quy tắc được gửi; khi một action khác đã gửi (và không action nào gặp lỗi xác thực), lần điều phối kết thúc sent và webhook thất bại chỉ hiển thị trong actionResults[].
Kết quả fire_webhook là sent có nghĩa là sự kiện đã được xếp hàng để chuyển tới URL của bạn, chứ không phải endpoint của bạn đã chấp nhận nó. Việc chuyển sau đó được thử lại theo lịch riêng của nó.
Biến template
send_dm.message, send_email.subject, và send_email.message hỗ trợ thay thế {{placeholder}}. Các placeholder không xác định bị từ chối tại thời điểm tạo/cập nhật (dưới dạng lỗi validation 473) để một lỗi đánh máy không bao giờ ngầm rò rỉ chuỗi ký tự {{foo}} vào một tin nhắn hướng tới khách hàng.
sender_email / recipient_email. Các placeholder này cố ý không được hiển thị — email thanh toán của bạn không có chỗ hợp pháp trong một DM tới người lạ, và Meta không cung cấp email của người nhận trên bất kỳ webhook IG nào. Việc tránh các placeholder ngăn ngừa việc tiết lộ ngẫu nhiên.Giới hạn tốc độ và giới hạn
POST (tạo) và kích hoạt lại PUT (active: false → true), mỗi lần đều hiển thị mã lỗi 470. Cần giới hạn cao hơn theo profile? Liên hệ hỗ trợ để tăng nó cho tài khoản của bạn.
Giới hạn DM hàng ngày áp dụng cho mỗi tài khoản Ayrshare cha, được chia sẻ trên tất cả profile của bạn, với một giới hạn phụ theo profile để một profile bận rộn không thể làm cạn hạn mức của toàn bộ tài khoản. Khi đạt đến giới hạn DM, hàng activity ghi lại trạng thái rate_limited và không có DM nào được gửi.
Giới hạn cuộc trò chuyện nhắn tin cũng được áp dụng. send_dm yêu cầu tiện ích bổ sung Messaging trên profile, và mỗi DM mà nó gửi đều được tính vào giới hạn cuộc trò chuyện hàng tháng của profile đó, giống như DM bạn tự gửi. Khi đạt đến giới hạn, một send_dm đến người nhận mới sẽ không được gửi và hàng activity ghi lại trạng thái failed, với thông báo giới hạn trong actionResults[].errorDetails. Các DM được kích hoạt bởi bình luận (comment_keyword và story_comment) là ngoại lệ: chúng vẫn được gửi khi đạt giới hạn và vẫn được tính.
Giới hạn cấu trúc trên một automation: 1–50 trigger, 1–50 action.
Chính Instagram giới hạn DM ở khoảng 200/giờ mỗi tài khoản. Engine điều chỉnh việc điều phối với một jitter 20–60 giây để giữ an toàn dưới mức này.
Trạng thái Activity
Một hàng trongGET /automations/:id/activity mang một status cấp cao nhất cộng với một status theo action bên trong actionResults[]:
pending và in_flight là tạm thời; mọi trạng thái khác là cuối cùng.
Khi một automation có nhiều hơn một action, status cấp cao nhất được suy ra từ các kết quả theo từng action theo thứ tự này: auth_error nếu bất kỳ action nào gặp lỗi xác thực, sau đó sent nếu bất kỳ action nào được chấp nhận, sau đó deduplicated nếu mọi action đều bị deduplicated, sau đó skipped nếu mọi action đều bị chặn có chủ đích (skipped hoặc deduplicated), nếu không thì failed. Đọc actionResults[] để biết chi tiết theo từng action.
sent là biên nhận nền tảng đã chấp nhận, chứ không phải biên nhận đã chuyển tin. Một action send_dm được đánh dấu sent ngay thời điểm Meta chấp nhận tin nhắn, dù tin nhắn được gửi từ tài khoản Instagram của bạn hay qua Messenger từ Trang Facebook của bạn. Automation chỉ ghi lại việc chấp nhận này; nó không theo dõi việc chuyển tin. Instagram không cung cấp thông tin delivery của tin nhắn cho bất kỳ API nào, và việc người nhận có thực sự nhận được hay không phụ thuộc vào thiết lập Message requests trên Instagram của họ, mà Ayrshare không thể đọc hay tác động tới. Xem Automation DM đã Gửi nhưng Không được Chuyển.Mã lỗi
API trả về hai dạng lỗi:- Lỗi quy tắc kinh doanh mang một
codeautomation được đánh số (ví dụ:{ "action": "automation", "code": 469, ... }). - Lỗi validation — bất kỳ body yêu cầu bị lỗi định dạng nào (trường thiếu hoặc không hợp lệ, biến template không xác định, khóa không được nhận dạng) — được trả về dưới dạng một phản hồi
473duy nhất với đối tượngdetailsliệt kê các trường vi phạm.detailslà kết quả của validator (formErrorscộng vớifieldErrors). Phân nhánh trêndetails, không phải trên mã theo điều kiện. TrongfieldErrors, các khóa là các trường yêu cầu cấp cao nhất (triggers,actions): một vấn đề bên trong một mục cụ thể, chẳng hạn như một trigger thiếukeywords, được báo cáo dưới trường đó (ví dụ:triggers), trong khiformErrorsgiữ các vấn đề cấp đối tượng như các khóa không được nhận dạng.
468 chỉ được trả về cho các gói
không bao gồm automation.Những gì Meta KHÔNG cho phép
Một số khả năng thường được yêu cầu không được hỗ trợ vì Meta không cho phép chúng trên Instagram API công khai:- Tự động DM cho người theo dõi mới. Instagram không xuất bản một webhook follow.
- DM tin nhắn đầu tiên cho người lạ. Meta yêu cầu người nhận phải tương tác trước (bình luận, trả lời, DM, phản ứng) trước khi một tài khoản doanh nghiệp có thể nhắn tin cho họ. Mọi trigger được hỗ trợ đều được neo vào một tương tác như vậy — nhưng lưu ý rằng được phép gửi không đồng nghĩa với việc tin nhắn được chuyển: thiết lập Message requests trên Instagram của người nhận vẫn có thể khiến Meta chấp nhận rồi âm thầm loại bỏ tin nhắn (xem Automation DM đã Gửi nhưng Không được Chuyển).
- Chiến dịch gửi hàng loạt. Giới hạn DM theo giờ và heuristic chống lạm dụng áp dụng ở cấp nền tảng.
Sử dụng đa profile
Các endpoint tôn trọng headerprofileKey. Truyền khóa của một profile con và automation được tạo/quản lý dưới profile đó. Giới hạn tốc độ được chia trên các profile thông qua một giới hạn phụ theo profile để một profile hoạt động sôi nổi không làm cạn hạn mức của tài khoản cha.
Câu hỏi thường gặp
Tôi có thể kích hoạt trên một người theo dõi mới không?
Tôi có thể kích hoạt trên một người theo dõi mới không?
comment_keyword, story_reply, dm_reaction, dm_keyword) đều được neo vào một tương tác như vậy, đó là điều khiến việc gửi được phép.Tại sao một activity ghi sent nhưng người nhận không bao giờ nhận được DM?
Tại sao một activity ghi sent nhưng người nhận không bao giờ nhận được DM?
sent có nghĩa là Meta đã chấp nhận tin nhắn, chứ không phải nó đã được chuyển. Điều này đúng trên cả Instagram và Facebook (Messenger từ Trang của bạn): automation chỉ ghi lại việc chấp nhận và không theo dõi việc chuyển tin. Trên Instagram, việc chuyển tin phụ thuộc vào thiết lập Message requests trên Instagram của người nhận — nếu họ không cho phép message request từ mọi người, Meta sẽ trả về phản hồi thành công rồi âm thầm loại bỏ tin nhắn, không có lỗi, webhook, hay bất kỳ tín hiệu nào khác trên mọi bề mặt API. Một DM kích hoạt từ bình luận được chuyển thành công cũng đến dưới dạng một message request mà người nhận phải chấp nhận (trừ khi một cuộc trò chuyện đã tồn tại). Đây là một giới hạn cố hữu của nền tảng Instagram. Xem Automation DM đã Gửi nhưng Không được Chuyển.Điều gì xảy ra nếu access token của tôi không hợp lệ khi một automation kích hoạt?
Điều gì xảy ra nếu access token của tôi không hợp lệ khi một automation kích hoạt?
auth_error và DM không được thử lại. Giải quyết trạng thái tài khoản (liên kết lại, chọn một Page, hoặc kích hoạt Messaging) cho phép tương tác khớp tiếp theo kích hoạt bình thường. Điều này chỉ áp dụng cho các thất bại thông tin xác thực và quyền thực sự: nếu một DM cụ thể không thể được chuyển vì lý do khác — ví dụ không tìm thấy người nhận, hoặc tương tác kích hoạt đến từ tài khoản sẽ gửi DM — hàng được ghi là failed hoặc skipped với lý do trên actionResults[].errorDetails, và việc liên kết lại sẽ không thay đổi kết quả.Tại sao có độ trễ trước khi DM được gửi?
Tại sao có độ trễ trước khi DM được gửi?
fire_webhook và send_email — webhook của bạn sẽ đến sau bình luận 20–60 giây, không phải ngay lập tức. Timestamp created của hàng activity là khi trigger khớp; completedAt là khi việc điều phối hoàn thành.Các hàng activity có được giữ mãi không?
Các hàng activity có được giữ mãi không?
GET /automations/:id/activity trả về các hàng từ 30 ngày qua để đảm bảo hiệu suất. (Bảo vệ dedup sử dụng cửa sổ theo action riêng của nó — mặc định là 7 ngày — không liên quan đến khoảng thời gian activity lookback.)Xóa một automation có xóa lịch sử activity của nó không?
Xóa một automation có xóa lịch sử activity của nó không?
deleted, không có điều phối mới nào xảy ra, nhưng các hàng activity lịch sử vẫn có thể đọc được qua endpoint activity.Endpoint
POST /automations— tạo một automation mớiGET /automations— liệt kê các automation của bạnGET /automations/:id— lấy một automation với các trigger và action của nóPUT /automations/:id— cập nhật một phần; tạm dừng quaactive: falseDELETE /automations/:id— soft-deleteGET /automations/:id/activity— nhật ký kiểm toán điều phối được phân trang theo cursor