Troubleshooting

Use this page when send results aren’t what you expected. Start with what to check for each symptom, then see the behavior behind it further down. For causes on the API side, go through the API integration guide with your development team.

Go through the When saving is rejected table in order.

• The field name in the message exactly matches the response (including case)
• If the API takes JSON via POST, you included :content_type application/json
• The value in the URL wasn’t broken by special characters (url_encode)
• No invisible spaces slipped in when you copied and pasted the URL
• Whether the circuit breaker was active
• The API meets the JSON header, 2xx response, 2 second, and 1MB conditions (check with your development team)

• The credential’s name, type, and allowed domain match the request URL
• Whether {% abort_message %} ran (failure reason: “Personalization syntax aborted”)
• Whether a Liquid render error occurred at send time

• Whether the circuit breaker was active
• The URL is reachable from outside and uses a standard port (80 or 443)
• :headers is a JSON object
• The message was actually sent (not rejected on save or failed)

• FlareLane’s outbound IPs are on your allowlist
• Requests with User-Agent: FlareLane-ConnectedContent/1.0 aren’t being blocked

• One call is made per instruction. Each field counts separately.
• If processing is retried after an error, the same recipient may be called again.
• Response reuse (cache) can reduce calls. For how reuse works, see Set up response reuse.

In most cases the message is sent with the value blank, but in some cases the recipient isn’t sent the message at all.

If an API keeps failing, FlareLane stops calling that API server for a while and sends the value blank. This helps the failing server recover and keeps each send from being delayed by 2 seconds per call. Writing fallback text with default: keeps you covered.