Use the X-EI SIP header
Use the X-EI SIP header
Use the X-EI SIP header
The X-EI header still works, but Synthflow now accepts any custom X-* SIP header on inbound calls. For most use cases, arbitrary X-headers are simpler and more flexible.
The X-EI SIP header lets you pass downstream call metadata from your SBC, PBX, or carrier into Synthflow so agents, analytics, and post-call workflows immediately inherit that context. Use it any time you need to correlate distributed call legs or identify where a transfer originated.
Twilio CallSid, carrier GUID, etc.) for every leg of a transfer so custom actions can cross-reference it without re-mapping IDs.X-EI.X-EI expects a semicolon-delimited list of tokens. Each token begins with one of three prefixes followed by a dot and the value:
You can send any subset of tokens in any order. All combinations are valid.
Avoid semicolons in the token values. Each token ends with ;, so additional semicolons break parsing.
Once the INVITE reaches Synthflow, the platform maps the token values to reusable placeholders for prompts, actions, and post-call workflows:
You can call these placeholders inside before-the-call or during-the-call custom actions without additional setup. The E. token also surfaces as call.external_id in the post-call webhook response.

In this example, we are passing E.someExternalID inside the Dial().sip(…) URI.
S + E, S + O, or all three.X-Diversion into the O. token automatically.external_id in webhooks? Confirm the E. token matches the format E.<your_id>; and isn’t URL-escaped twice.X-Diversion is present.