Instagram API errors 2534022, 2534025, and 10900: fixing Private Reply and 24-hour window failures

If you maintain an Instagram Comment-to-DM automation workflow in n8n, Make, a custom Node/Python worker, or a third-party automation tool, you will eventually run into three Graph API errors in your logs:

• code: 10, error_subcode: 2534022: This message is sent outside of allowed window.
• code: 100, error_subcode: 2534025: The comment is invalid for a private reply.
• code: 10900: Activity already replied to (or This comment has already been replied to).

Most online forum threads lump 2534022 and 2534025 together, which sends developers chasing the wrong bug. One is a conversation-window error; the other is a comment-eligibility or payload error. Here is what Meta's official Private Replies endpoint enforces on the server and how to fix each failure cleanly.

1. How Meta's Private Reply endpoint works under the hood

When someone comments on your Instagram post, Reel, Ad, or Live stream, you cannot message them using a standard recipient.id call unless they already have an open 24-hour DM thread with your account. Trying to do so returns 100 / 2534014 (No matching Instagram user) or 10 / 2534022 (Outside of allowed window).

Instead, your first outbound message must go out as a Private Reply referencing the comment_id:

POST https://graph.instagram.com/v21.0/{ig-user-id}/messages
Content-Type: application/json

{
  "recipient": {
    "comment_id": "18000158536435933"
  },
  "message": {
    "text": "Hey! Tap below to grab the guide:"
  }
}

When that request succeeds, Meta returns both the message_id and the user's Instagram-scoped ID (recipient_id / IGSID). If the commenter follows your account, the message lands in their primary Inbox. If they do not follow you, it lands in their Message Requests folder along with a preview link to the post they commented on.

Meta enforces four strict server-side rules on this flow:

---

2. Fixing Error 10 / 2534022: "This message is sent outside of allowed window"

{
  "error": {
    "message": "(#10) This message is sent outside of allowed window.",
    "type": "OAuthException",
    "code": 10,
    "error_subcode": 2534022,
    "fbtrace_id": "A9xK2..."
  }
}

Cause A: Trying to send two messages in a row after a comment trigger

Suppose you want your automation to send a greeting message first, wait three seconds, and then send a link card. If your workflow calls POST /messages twice after a comment trigger, Message #1 succeeds via comment_id, and Message #2 fails immediately:

• If you pass comment_id a second time, Meta rejects it with 10900 (Activity already replied to).
• If you pass the recipient_id returned by Message #1 before the user has replied, Meta rejects it with 10 / 2534022 (This message is sent outside of allowed window).

Sending a Private Reply does not open a two-way 24-hour messaging window. As Meta's Private Replies documentation states, "Only when the Instagram user responds to the private message can you continue the conversation within the 24-hour messaging window."

How to fix it:

• Put a Postback Button or Quick Reply on your initial Private Reply (or ask the user to reply with a keyword if they are a non-follower).
• Wait for the messaging_postbacks or messages webhook event when the user taps the button or replies.
• Once that event arrives, the 24-hour standard messaging window is open on their IGSID, and you can check their follower status, send multi-card carousels, attach voice notes, and schedule follow-up reminders.

Cause B: Follow-up sequence scheduled past 24 hours

Once a user messages your inbox or taps a button, you have a rolling 24-hour window from their last interaction to send automated messages. If your workflow waits 24 hours (or 48 hours) to send a "Did you get a chance to check out the link?" nudge, the API call lands a few seconds after the window closes and fails with 2534022.

How to fix it: Schedule timed follow-up reminders between 4 and 22 hours after the user's last button tap or reply, never at 24+ hours.

---

3. Fixing Error 100 / 2534025: "The comment is invalid for a private reply"

Meta returns code: 100, error_subcode: 2534025 (or (#100) The comment cannot be replied to privately) when the comment object or payload fails validation on the Private Reply endpoint.

Cause A: Backfilling comments older than 7 days (or after an Instagram Live ends)

For standard posts, Reels, and Ads, the Private Reply window lasts 7 days (168 hours) from the comment timestamp. If you connect an automation tool on Wednesday to backfill comments from a Reel that went viral the previous week, any comment older than 168 hours fails.

For Instagram Live (live_comments webhook), the rule is much stricter. Many blogs mistakenly claim you get 24 hours after a Live stream. Meta's official Private Replies spec states that Private Replies on Instagram Live comments can only be sent while the Live broadcast is actively running. The moment you end the Live stream, any remaining queued live_comments fail with 2534025.

How to fix it:

• In custom workers, check Date.now() - commentTimestampMs < 7 * 24 * 60 * 60 * 1000 before calling /messages.
• For comments older than 7 days (or after a Live ends), post a public comment reply (POST /{comment-id}/replies) instead: "Hey! Drop me a quick DM with the word GUIDE and I'll send the link right over." Public comment replies do not have a 7-day cutoff.

Cause B: Unsupported attachment data in a Private Reply (or Subcode 2534015)

Meta's table notes for 2534025: "Make sure that the type of data you are sending in your private reply is allowed." You cannot send every rich attachment type inside the initial comment_id Private Reply (and sending interactive buttons to non-followers can also trigger 1545133).

How to fix it: Keep your initial comment_id Private Reply simple (plain text or a single postback prompt to open the 24-hour window), then deliver multi-card product carousels, audio voice notes, and follow-up links on step two after the user taps or replies.

Cause C: The user deleted their comment while it sat in your queue

During viral spikes where hundreds of comments arrive per minute, a user will often post a typo ("GUDE"), delete it five seconds later, and comment again ("GUIDE"). When your worker processes the job for the deleted comment_id, Meta returns 2534025 or 100 / 33 (Unsupported post request. Object with ID does not exist).

How to fix it: Treat 2534025, 2534022, and 100 / 33 as non-retryable terminal errors in BullMQ, Celery, or SQS. Retrying a deleted comment ID with exponential backoff wastes your 200 calls/hour API rate limit and slows down real commenters waiting in your queue.

---

4. Fixing Error 10900 and Instagram Ad comment failures

When Meta returns Error 10900 (Activity already replied to), a Private Reply has already been sent for that comment_id.

How RapidDM handles these edge cases automatically

If you would rather not maintain webhook deduplication, two-step window state machines, and rate-limit queues yourself, RapidDM handles the Graph API plumbing out of the box:

• Idempotent comment_id deduplication so duplicate webhook deliveries from boosted posts or ads never trigger double-sends or 10900 errors.
• Automatic Private Reply fallback and two-step flows that transition commenters from the initial comment_id reply into an open 24-hour DM conversation for Ask-to-Follow checks, 10-card product carousels, and voice notes.
• Per-account Redis rate-limit queuing that paces viral comment spikes under Meta's 200 calls/hour limit while staying inside the 7-day window.
• Free plan included: Start with 1,000 free automated DMs per month, or upgrade to Pro for unlimited DMs and up to 3 Instagram accounts ($19/month, $15/month billed quarterly, $11/month billed yearly, or ₹499/month in India).