Data Manager API defines INVALID_MERCHANT_ID for a merchant ID that is invalid, including values with non-digit characters. Store sales pipelines often populate the field from a display label, prefixed account string, spreadsheet-formatted value, or the wrong WordPress store mapping, so the rejected event must be traced back to its source record.
Use this for WordPress and WooCommerce store-sales uploads to Google Data Manager API when request status reports INVALID_MERCHANT_ID for one or more events in a batch.
Quick answer
Use request status to locate the rejected event and field path, then trace merchant ID back through the normalized event, CRM or store map, and WordPress source. Require a nonempty digits-only canonical string from the approved account mapping. Fix the source mapping, replay only rejected idempotent events, and verify the final status.
What to check first
- Record request ID, event index, error reason, field path, order or event ID, source system, source field, merchant mapping version, raw value, and normalized value.
- Check for prefixes, labels, spaces, punctuation, spreadsheet scientific notation, decimal suffixes, leading apostrophes, nulls, and a store code copied into the merchant field.
- Verify the merchant ID belongs to the intended Google account and store-sales destination rather than a conversion action, customer, location, or Merchant Center label.
- Validate before batching and quarantine invalid rows with safe identifiers so one mapping problem does not require blind replay of accepted events.
- Correct the authoritative store-to-merchant map, rebuild rejected events from source, preserve deduplication keys, resend narrowly, and retrieve terminal status.
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 |
|---|
| Retrieve the field-level error | Record request ID, event index, error reason, field path, order or event ID, source system, source field, merchant mapping version, raw value, and normalized value. | The request-status error path maps to one source event. |
| Trace the value to its source mapping | Check for prefixes, labels, spaces, punctuation, spreadsheet scientific notation, decimal suffixes, leading apostrophes, nulls, and a store code copied into the merchant field. | Normalized merchant ID passes digits-only and account ownership checks. |
| Normalize and validate before batching | Verify the merchant ID belongs to the intended Google account and store-sales destination rather than a conversion action, customer, location, or Merchant Center label. | The corrected source map is versioned and used by new events. |
| Correct the authoritative store map | Validate before batching and quarantine invalid rows with safe identifiers so one mapping problem does not require blind replay of accepted events. | Narrow replay succeeds without duplicating previously accepted events. |
Why this usually happens
- Human-readable account labels are copied instead of the numeric identifier.
- CSV and spreadsheet tools can alter large numeric strings or append decimal notation.
- Multi-site WordPress mappings can assign the right format to the wrong store.
- A batch-level success response can precede event-level processing errors visible through request status.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
request_id: dm-20260725-8821
event_index: 14
error_reason: INVALID_MERCHANT_ID
field_path: events[14].destination.storeSales.merchantId
raw_value: 'merchant-1234567890'
normalized_value: '1234567890'
digits_only: true
source_map_version: stores-v19
dedupe_key: order-88421-store-03
retry_status: SUCCESS
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.
- Retrieve the field-level error
- Trace the value to its source mapping
- Normalize and validate before batching
- Correct the authoritative store map
- Replay rejected events and confirm status
Decision rule
Pass when every event uses the approved digits-only merchant ID for its store, invalid rows are blocked before upload, accepted events are not duplicated, rejected events replay with the same business identity, and request status reaches success.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- The request-status error path maps to one source event.
- Normalized merchant ID passes digits-only and account ownership checks.
- The corrected source map is versioned and used by new events.
- Narrow replay succeeds without duplicating previously accepted events.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, or delayed background work.
- Do not paste secrets, personal data, or complete production payloads into tickets or screenshots.
- Do not close the test until the final user-visible state and server-side evidence agree.
Questions teams ask during testing
Can I remove non-digit characters automatically?
Only if the source field is known to contain the correct ID with formatting noise. Do not turn an arbitrary label into a plausible but wrong account number.
Why did the send request succeed if an event was invalid?
Asynchronous processing can report event-level errors later. Retrieve request status and reconcile every submitted event before closing the batch.
When HandL WP should help
Bring in HandL WP when this affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, fix a Data Manager API store-sales upload.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references