Place auth and transaction metadata in the correct SOAP header shape so the carrier can authenticate, trace, and support the request.
Headers Carry the Operational Contract
SOAP headers hold metadata that should not be mixed into the business payload: auth tokens, transaction IDs, routing hints, and sometimes WS-Security blocks. If those fields drift into the body or the wrong namespace, the request may still look valid XML while the carrier rejects it immediately.
Auth Tokens Must Live in the Right Namespace
SOAP auth is often expressed through a header contract, not a generic HTTP bearer token alone. Some carriers expect UsernameToken, API keys, access-license data, or a transaction block in specific namespaces and specific element order. Treat that structure as part of the contract, not as incidental boilerplate.
Carrier Reality
Legacy carrier SOAP stacks often keep HTTP auth, WS-Security, and carrier-specific transaction headers as separate concerns. A request can reach the endpoint successfully while still failing application auth because one header block used the wrong namespace prefix or element name.
Correlation IDs Turn Support Into Search
Support escalations move faster when the same request identifier appears in your logs, the carrier's logs, and the SOAP header contract. If correlation IDs are optional, inconsistently named, or omitted on retries, your incident evidence becomes fragmented precisely when you need it most.