Data Manager API can reject an event with BOTH_CLIENT_ID_AND_APP_INSTANCE_ID_NOT_ALLOWED when the payload includes both a web client ID and an app instance ID in a context that accepts only one. WordPress tracking pipelines can create this accidentally by merging browser cookies, server event records, CRM fields, and mobile-app data into a shared user-data object. Removing one field blindly can damage matching for another source type.
Use this for WordPress lead and commerce pipelines that upload events through Data Manager API, especially systems sharing schemas between web, mobile app, server, CRM, and batch jobs. Keep user-data handling within the approved consent, account, and source relationship.
Quick answer
Locate the exact failed event and field path from request-level diagnostics, then trace client ID and app instance ID back to their collection sources and transform versions. Classify the event as web, app, or another supported source and select the one identifier allowed by that schema. Validate the corrected single event, rebuild only affected records with the same event IDs, and replay through a bounded queue.
What to check first
- Preserve request ID, batch ID, event ID, event source, destination, error reason, field path, transform version, collection timestamp, and consent state.
- Trace client ID to the browser or analytics cookie source and app instance ID to the app SDK or approved server record without exposing raw values in shared logs.
- Inspect merge, fallback, default, coalesce, and shared user-data builder logic that can populate both fields after separately valid collection.
- Compare the payload against the event source and destination contract, then test web-only, app-only, neither, and intentionally invalid both-present fixtures.
- Replay only corrected eligible events with stable event IDs and monitor accepted, partial, duplicate, expired, and newly rejected outcomes.
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 |
|---|
| Quarantine the failed subset | Preserve request ID, batch ID, event ID, event source, destination, error reason, field path, transform version, collection timestamp, and consent state. | Invalid both-present fixtures fail before network upload. |
| Trace both identifier origins | Trace client ID to the browser or analytics cookie source and app instance ID to the app SDK or approved server record without exposing raw values in shared logs. | Web and app fixtures contain only their allowed identifier. |
| Classify the event source contract | Inspect merge, fallback, default, coalesce, and shared user-data builder logic that can populate both fields after separately valid collection. | Corrected events retain event IDs, timestamps, consent, and destination. |
| Correct the shared identity transform | Compare the payload against the event source and destination contract, then test web-only, app-only, neither, and intentionally invalid both-present fixtures. | The bounded replay creates no duplicate conversion or new field-level rejection. |
Why this usually happens
- A shared identity model can merge identifiers from different platform contexts.
- A fallback transform may append a second identifier instead of choosing one.
- CRM exports can preserve stale app data on a web conversion record.
- Client-side and server-side payload builders may each add their preferred identifier.
- Batch-level success can hide field-level rejection for a subset of events.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
event_id: lead-8841
source: WEB
before:
client_id: present
app_instance_id: present
error_reason: BOTH_CLIENT_ID_AND_APP_INSTANCE_ID_NOT_ALLOWED
after:
client_id: present
app_instance_id: omitted
transform_version: identity-map-v7
consent_state: approved
replay_status: accepted
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.
- Quarantine the failed subset
- Trace both identifier origins
- Classify the event source contract
- Correct the shared identity transform
- Replay with stable event IDs and monitor results
Decision rule
Send only the identifier permitted for the proven event source and schema. Do not choose based on whichever value is easiest to collect. If source identity or permission is ambiguous, hold the event until it can be classified.
What to tell the client or owner
Give the site owner the affected version, 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
- Invalid both-present fixtures fail before network upload.
- Web and app fixtures contain only their allowed identifier.
- Corrected events retain event IDs, timestamps, consent, and destination.
- The bounded replay creates no duplicate conversion or new field-level rejection.
Mistakes to avoid
- Do not delete app instance ID from every pipeline globally.
- Do not log raw identifiers in shared incident channels.
- Do not rebuild event IDs during a corrective replay.
- Do not treat batch acceptance as proof that each event was accepted.
Questions teams ask during testing
Which identifier should a WordPress web lead normally use?
Use the identifier supported by the documented web event contract and the actual collection source. Do not attach app identity without a real app context.
Can hashing resolve this error?
No. The error concerns mutually exclusive fields and event context, not the representation of the identifier.
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 upload.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references