AFI
Logs and Troubleshooting
When an integration does not do what you expected, the log tells you which of two very different things happened: the integration ran and the platform refused it, or the integration never ran at all. Those need opposite fixes, so start here rather than guessing.
The log
AFI → Log lists every request AFI has sent, newest first. Each row records the integration it belongs to, the HTTP status code, the platform’s response message, and the time.
Open a row to see the full detail: the URL that was called, the request payload exactly as it was sent including headers, and the platform’s complete response body.
The payload view is usually where the answer is. It shows the values after mapping, after special tags were resolved, and after shortcodes were parsed, which is to say what the platform actually received rather than what you intended to send.
Logging is on by default and can be turned off in General Settings, along with an optional retention window that deletes old rows automatically.
Reading status codes
| Status | What it means | Where to look |
|---|---|---|
| 200, 201, 202 | Accepted | Nothing to fix |
| 400, 422 | The platform rejected the payload | The response body names the offending field |
| 401, 403 | Credentials rejected | Re-enter them in AFI → Settings |
| 404 | Wrong endpoint, or the target record does not exist | Check IDs such as list or pipeline |
| 429 | Rate limited | Turn on the job queue, or reduce volume |
| 5xx | The platform had a problem | Retry later, it is usually not your configuration |
| Transport error | The request never left your server | Firewall, DNS, or an outbound connection block |
A 2xx status means the platform accepted the request. It does not always mean the record appeared where you expected. Some platforms accept a payload and then discard fields they do not recognise, so if the status is green but the data is missing, compare the field names in the request payload against the platform’s own field list.
Integration health
The AFI → Integrations list shows recent health for each integration alongside the row: how many runs it has had over the recent window, what proportion returned a 2xx, and a small chart of daily volume.
A Failing tab filters the list down to integrations that recorded at least one non-2xx response in the last week. This is deliberately broad, so an integration appears there even if its most recent run succeeded. A single failure a few days ago is still worth knowing about, because the usual cause is an expiring credential rather than a one-off blip.
An integration with no runs at all shows no statistics. That is a meaningful signal in itself: the trigger has never fired.
No log entry at all
If there is no row for the submission, the request was never sent. Work through these in order.
Is the integration active? An inactive integration is skipped silently. Check the status column on AFI → Integrations.
Does the trigger match? The form plugin and the specific form both have to match the submission. Duplicating a form in your form plugin gives it a new ID, and an integration pointing at the old ID stops firing without any warning.
Did conditional logic hold it? Conditional logic runs before the API call, so a held submission produces no log entry. Temporarily switch conditional logic off and submit again. If the entry appears, a rule is not matching what the form actually sends. See Conditional Logic.
Is the job queue stuck? With the queue enabled, the request is sent by a background job. If WordPress cron is not running, the job waits and no log row is written yet. The queue health card in General Settings shows pending count and last run time.
Did the form actually submit? Some form plugins fire their completion hook only after a successful save. If the form has a validation error or a failing spam check, nothing downstream runs.
Values arriving empty or wrong
A field is empty in the payload. The mapping points at a field name the form does not send. Submit once with every field filled and read the request payload in the log to see the real names.
A field arrives with the wrong value. Two fields with similar labels are easy to swap. The payload view resolves this quickly.
A special tag arrives blank. User tags are blank for visitors who are not logged in. Page tags are blank when the submission has no page context. UTM tags are blank when that visitor never arrived with the parameter. See UTM Parameters and Special Tags.
A tag arrives as literal text. It was typed rather than picked from the dropdown, and the key does not match. Choose it from the mapping dropdown instead.
A checkbox or multi-select arrives oddly formatted. Multiple values are combined into one string. If the platform wants them separated differently, that is usually a per-platform mapping option rather than something wrong.
Failures that repeat
An integration failing on every submission is nearly always credentials or a required field.
Credentials expire, get rotated, or are revoked when someone leaves the team. A run of 401s that starts on a particular day and never stops is that. Re-enter them in AFI → Settings for the platform, then submit a test.
A required field the platform silently gained is the other common cause, and it shows up as 400 or 422 with a message naming the field.
Turn on Send Error Email in General Settings so you hear about this without checking. Notifications are throttled to one per hour for each integration and status code, so a broken credential does not flood your inbox.
Getting help
If you need support, the two most useful things to include are the integration ID and the full contents of a failing log entry, with any personal data removed. That combination usually identifies the cause without any back and forth.