Google announced that starting June 15, 2026, new adopters of offline conversion imports and enhanced conversions for leads should use the Data Manager API rather than the legacy Google Ads API upload path. If a WordPress lead pipeline suddenly rejects uploads, verify the API path before rewriting form tracking.
Use this for WordPress sites, agencies, and lead-generation teams importing qualified leads from Gravity Forms, Elementor, Contact Form 7, WooCommerce, or a CRM into Google Ads.
Quick answer
Data Manager API Fix When Google Ads API Uploads Are Blocked should be handled with a narrow evidence-first workflow: identify api path, check token access, map fields, then verify the result before making broader changes.
What to check first
- Confirm whether the account is using legacy Google Ads API uploads or the Data Manager API.
- Check whether the developer token is allowlisted for legacy access or blocked as a new adopter.
- Map form lead ID, click ID, consent state, CRM stage, conversion action, time zone, and hashed user data.
- Preserve rejected upload diagnostics instead of dropping failed rows silently.
- Run a small test upload and compare Google Ads diagnostics against the source CRM record.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
| Identify API path | Confirm whether the account is using legacy Google Ads API uploads or the Data Manager API. | The upload path is Data Manager API for current and future offline conversion imports. |
| Check token access | Check whether the developer token is allowlisted for legacy access or blocked as a new adopter. | Every accepted row maps back to a WordPress form or CRM record. |
| Map fields | Map form lead ID, click ID, consent state, CRM stage, conversion action, time zone, and hashed user data. | Rejected rows include enough detail to fix field, consent, or timing problems. |
| Preserve diagnostics | Preserve rejected upload diagnostics instead of dropping failed rows silently. | Google Ads reports the intended qualified conversion action, not raw form submits. |
Why this usually happens
- A script copied from an older Google Ads API implementation is deployed for a new account.
- The upload endpoint changes but the WordPress form fields stay incomplete.
- A CRM sends qualified leads without click IDs, consent state, or stable lead IDs.
- The team fixes the API error but forgets to test matching and deduplication.
Field notes
- Treat this as a pipeline migration, not only an endpoint change.
- Do not send restricted user data when consent or policy does not allow it.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
upload_diagnostic:
source: gravity_forms
legacy_endpoint: UploadClickConversions
new_path: Data Manager API
lead_id: gf-18825
conversion_action: qualified_lead
consent_state: granted
click_id_present: true
result: migrate uploader and preserve rejected rows
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Identify API path
- Check token access
- Map fields
- Preserve diagnostics
- Run test upload
What to tell the client or owner
Tell marketing whether uploads failed because of API access, missing fields, timing, consent, or conversion-action mapping.
Production verification checklist
- The upload path is Data Manager API for current and future offline conversion imports.
- Every accepted row maps back to a WordPress form or CRM record.
- Rejected rows include enough detail to fix field, consent, or timing problems.
- Google Ads reports the intended qualified conversion action, not raw form submits.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, migrate WordPress leads to Data Manager API.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references