Read and resolve Manychat delivery errors

Before you start

Open the affected conversation in Chats and find the failed reply. Expand Message details on that turn to see the diagnostic. This guide applies when Manychat delivery details is shown. If no incoming message or generated reply exists, start with the automation troubleshooting guide instead. Delivery diagnostics explain the response from Manychat; they do not prove that the customer's device displayed a message.

Keep the connected account and automation in view. Fields, contacts, and flows belong to an account, so a correct-looking identifier from another account can still fail. Read the diagnostic before changing credentials or repeatedly running the flow.

Read the diagnostic

1. Identify the step: Updating Manychat fields means SiloBox was writing response values; Starting the Manychat reply flow means it was asking Manychat to run the delivery flow.
2. Read the reason and any field validation details. Note the HTTP status, Manychat error code, and field batch when present. Original provider wording may be shown with sensitive values redacted and long details shortened.
3. Check the outcome note. A field-update failure means the reply flow was not started, although some contact fields may already have changed. A rejected flow request differs from an uncertain result where the flow may already have started.
4. Apply the matching correction below. Change the affected setting, save it, and inspect Manychat before retrying if the result was uncertain.
5. Send one new test message after the correction. Verify the response in the original channel and review the new conversation event rather than expecting the historical error to disappear.

Match the reason to the correction

• Credentials or permission: check the saved Manychat account, API token, permissions, and plan access. Use the account's integration check to narrow a connection problem.
• Field or validation: refresh account fields and inspect each mapped destination. Check whether the value must be text, a number, or true/false, and whether blank or null values were rejected.
• Flow or contact: confirm the Responses flow is published in the selected account and the contact belongs to that account. A display name is not a flow identifier.
• Messaging window: follow the channel's current rules before sending again. Repeated retries do not remove a restriction.
• Rate limit or service error: allow time before retrying and check the provider's service status where appropriate.
• Network, unrecognized response, or unknown rejection: preserve the request ID and displayed codes for support. Check for an already-started flow before another attempt.

Check the result

Success means a new test updates the intended fields, starts the intended reply flow, and produces the expected message in the channel. Do not treat a missing diagnostic panel alone as proof of delivery. If the issue persists, share the diagnostic step and codes with support, without tokens or unnecessary customer information.

Distinguish preview from a real send

A prompt test and mapping preview cannot verify channel delivery. The live test uses the saved published automation and a real subscriber, updates fields, and may send messages after confirmation. A stale result means the configuration changed and needs a new test. Accepted by Manychat is confirmation of provider acceptance; still check the actual conversation. If a route or Responses flow changed, verify the channel, account, Automation ID, and delivered buttons as well as text.

Related guides

• Automation not replying
• Connect Manychat
• Connect and test flows
• Contact support