The Data Manager API returns a request ID for ingestion work and provides request status diagnostics such as success, processing, failed, or partial success. WordPress lead pipelines need to retain that ID and translate error counts into safe retry decisions.
Use this for agencies and advertisers uploading WordPress leads, offline conversions, audiences, or transaction data through the Data Manager API.
Quick answer
Data Manager API Request Status Partial Success Runbook should be handled with a narrow evidence-first workflow: persist request id, poll status, classify errors, then verify the result before making broader changes.
What to check first
- Store the request ID with batch time, destination, conversion action, row count, and internal batch ID.
- Poll request status until it reaches a terminal state instead of treating HTTP acceptance as completion.
- Group errors by reason, including consent, duplicate IDs, invalid click IDs, timing, and format.
- Separate permanent data errors from temporary internal failures before building a retry batch.
- Reconcile accepted, failed, retried, and suppressed row counts back to the source leads.
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 |
|---|
| Persist request ID | Store the request ID with batch time, destination, conversion action, row count, and internal batch ID. | Every ingestion batch has a retained request ID and source batch reference. |
| Poll status | Poll request status until it reaches a terminal state instead of treating HTTP acceptance as completion. | Terminal status and error counts are stored without raw personal data. |
| Classify errors | Group errors by reason, including consent, duplicate IDs, invalid click IDs, timing, and format. | Retries include only eligible failed rows and preserve deduplication keys. |
| Build safe retry | Separate permanent data errors from temporary internal failures before building a retry batch. | Source, accepted, failed, suppressed, and retried counts reconcile. |
Why this usually happens
- HTTP acceptance confirms the request shape, not every downstream record outcome.
- One batch can contain records with different consent, identifier, or timing quality.
- Blind retries can duplicate conversions that already succeeded.
- A request ID that is not stored leaves support teams unable to retrieve diagnostics.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
GET https://datamanager.googleapis.com/v1/requestStatus:retrieve?requestId=REQUEST_ID
request_log:
request_id: req-a82
source_batch: wp-leads-2026-07-11-01
accepted: 486
retry_eligible: 3
suppress: 11
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.
- Persist request ID
- Poll status
- Classify errors
- Build safe retry
- Reconcile counts
What to tell the client or owner
Give support the request ID, destination, batch ID, counts by status and error reason, retry decision, and final reconciliation.
Production verification checklist
- Every ingestion batch has a retained request ID and source batch reference.
- Terminal status and error counts are stored without raw personal data.
- Retries include only eligible failed rows and preserve deduplication keys.
- Source, accepted, failed, suppressed, and retried counts reconcile.
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, audit WordPress offline conversion uploads.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Map structured errors to owned WordPress fields
Use the Data Manager API request status and field path parser to tokenize synchronous field violations, preserve aggregate asynchronous reasons, and map safe diagnostics to the WordPress form, order, CRM, or transform owner.
Preserve future errors and isolate reproducible batches
Keep new enum values visible with the Data Manager API unknown ErrorReason alert. When aggregate partial success remains reproducible and replay is safe, use the partial-success batch bisection guide to narrow the failing group without inventing row attribution.
Handle long-running and divergent destination states
Apply the Data Manager API 24-hour stale request SLA for durable backoff, jitter, caps, and owner escalation. Use the per-destination partial-success guide when one request has different terminal outcomes, reasons, retries, and reporting effects.
Prevent duplicate request-status pollers
When request status is asynchronous, use the Data Manager API duplicate polling lease monitor to fence worker ownership, preserve backoff, stop at terminal state, and prevent duplicate retries or alerts.
Helpful references