A successful HTTP response from the Gravity Forms results API is not enough to approve a survey report. Check the response's completion state, the population selected by the request and the meaning of each total. A complete aggregate can still disagree with your CSV because the two reports include different entries.
This article is for developers connecting survey results to a dashboard or reporting job. For a manual download, use the existing Gravity Forms survey CSV export guide. Do not replace a working export process with an API integration merely to retrieve a one-off file.
Know Which Interface You Are Calling
Gravity Forms documents GET /gf/v2/forms/[FORM_ID]/results for Survey, Polls and Quiz results. The official results API reference describes entry_count, field_data, labels, status and a calculation timestamp. Results can be complete or incomplete. The endpoint normally requires gravityforms_view_entries; installations can customize that capability check.
These are aggregate results, not a row-by-row export. Preserve field identifiers when interpreting field_data and labels. Do not assume that every number means respondents: the meaning depends on the question and add-on.
First Separate Access Failure From Reporting Failure
Verify the site, form ID and configured authentication through your existing approved integration. Keep credentials out of query strings, screenshots and shared logs. A 401 or 403 needs an authentication or permission investigation, not a change to spreadsheet formulas.
Use a dedicated integration identity with the required access. Test it against an approved small form. Do not grant an administrator role just because the first request failed. The least-privilege role mapping guide can help distinguish the intended capability from unrelated permissions.
Before investigating arithmetic, confirm the response is JSON from the expected endpoint. An HTML sign-in page, firewall response or generic proxy error is not a survey result even if an intermediary returned HTTP 200.
Give Incomplete Results Their Own State
Design the report consumer to distinguish at least three outcomes: request failure, incomplete calculation and completed calculation. Do not render an incomplete result as a final zero or silently reuse it as today's approved report.
A practical reporting job can retain the last reconciled report, label it with its actual calculation or retrieval time, and separately show that a new calculation is pending. Set a bounded retry policy and an operational alert threshold appropriate to your reporting deadline. Constantly polling faster does not explain why calculation has stopped progressing.
Record the returned timestamp across attempts, along with completion status and retrieval time. If it does not advance when expected, inspect the site's scheduled processing and relevant errors. Do not delete or reset results as a first troubleshooting step. Preserve the small request and response that demonstrate the problem.
Synthetic four-entry example: three active respondents are included, one spam entry is excluded, and the active totals are Email two and Phone one.
Compare Identical Populations Before Totals
The API reference documents a JSON search argument, an active entry-status default, and field-filter matching modes. Save the exact request configuration beside the report. Then compare it with the CSV export's actual status and conditional filters, rather than assuming the defaults match.
For a bounded test, create a synthetic form or approved staging fixture with known answers. Keep unrelated live submissions out of the comparison. Verify any additional search behavior you need on the installed version instead of borrowing unsupported parameters from another endpoint.
| Fixture record |
Included in active-only test? |
Single-choice answer |
| A, active |
Yes |
Email |
| B, active |
Yes |
Phone |
| C, active |
Yes |
Email |
| D, spam |
No |
Phone |
In this illustrative fixture, the expected active respondent count is three. Email has two and Phone has one. A CSV that intentionally includes the spam record answers a different question and should not be expected to match. This is synthetic arithmetic, not a measurement from a customer survey.
Avoid a Second Error When Flattening Results
Retain the field ID, choice identifier and label as separate columns in your reporting transformation. Labels can change and need not be unique across questions. A convenient display string is a poor database join key.
Run a second fixture with one unanswered question and a multi-select question. Make the report say whether a percentage uses all eligible entries, question answerers or selections. Do not force multi-select percentages to sum to 100% unless the measure is explicitly share of selections.
Keep ranking and score summaries separate from ordinary choice counts until their semantics are verified. A total score of twelve is not evidence that twelve people answered. If you cannot explain a field's meaning from the form definition and a known example, exclude it from the headline dashboard until you can.
Approve an Automated Report With Evidence
Acceptance requires the intended identity and form, a complete response, documented filters and a small dataset whose expected totals match both interfaces. Save redacted fixtures and transformation tests so a plugin update cannot silently change the report.
Retest after changing survey choices, scoring or filters. The historical survey choice audit covers changes to question meaning. For unexplained disagreement between an API dashboard and the underlying entries, HandL WP can trace the reporting integration using a minimal authorized sample rather than a bulk customer-data export.
References checked October 26, 2026. Procedures and synthetic diagrams are explanatory, not claims of customer testing.