Connect an application's phone and browser entry points

Use this task to add or change the way an existing application receives an interaction. An entry point is a declaration in the flow. An endpoint is the persisted application route used when starting a call or browser session. They are related, but are not always one entry point per endpoint.

Availability: Work in the app's team with permission to edit its flow. Draft editing, publication and infrastructure access are separate permissions; start with Access and teams when an action is unavailable. Publication also checks subscription and flow readiness. Browser integration requires the deployment's API enablement and appropriate team scopes; voice additionally requires WebRTC and its infrastructure.

Use a designated test application/destination, record existing live routes, and agree who may publish. Do not experiment with another team's telephone number or assume all Flow Designer tests leave live endpoints untouched.

1. Choose the route and confirm its owner

Intended route	Authored entry type	Result to verify
Telephone call	phone	The assigned base number, and extension when enabled, reach this flow through the intended SIP route.
Browser conversation with voice	web_voice	The browser application starts an authorized voice session against this app's browser endpoint.
Browser text conversation	web_chat	The browser application starts a text session that reaches the intended flow path.

The flow's AI nodes must support the interaction you intend. Adding a chat entry does not convert every voice-only node into a text handler. Use Choose a channel and provider configuration to check that processing path.

For phone routes, have the administrator prepare the base number and team assignment using SIP routing. For browser routes, agree on the application origin, permitted network context and session mode with the integration owner using Connect a browser application.

2. Open the entry-point controls

Open the app's Flow Designer, then Flow Settings → Endpoints. Select an existing entry-point row or canvas entry-point chip to open its inspector.

• To add a phone route, use Add phone number and select the phone option. Open the new row to configure it.
• In Browser, use Voice Channel or Chat Channel to enable the intended channel, then Configure to open its settings. The Actions channel has a separate browser-action workflow; it is not a synonym for a voice/chat entry.
• Review the flow after adding a channel. Channel setup can prepare shared flow structure; do not assume changing a toggle only changes a label.

Browser controls and text runtime have different availability rules. In this editor, the Browser block, including its Chat Channel control, is shown through the WebRTC feature gate. If the block is absent, ask the operator about that UI feature condition. This does not prove the text-session API requires WebRTC: its text mode has separate prerequisites. Use the browser integration guide to resolve runtime availability rather than enabling unrelated services blindly.

3. Configure a phone entry point

Control	What to do and what changes
Base Number	Choose the number assigned to this app's team. Selecting a different base number clears the extension field, so review it again.
Extension Code (3 digits)	Supply exactly three digits when the selected number has extensions enabled. Do not use an extension when it has them disabled.
Advanced → Phone Number (DID)	Additional authored phone-number value. It does not replace the required Base Number selection or grant ownership of a number.
Advanced → Egress Base Number	Select the intended outbound/transfer routing base number when applicable. The selector appears only when available numbers have egress trunks. Inbound number assignment and outbound routing are different decisions.

The server checks that the base number exists and belongs to the app's team. It rejects route conflicts with other assigned endpoints. A number with extensions disabled cannot be used directly while assigned to multiple teams. If a conflict is reported, ask the routing owner to resolve the existing assignment; changing a display value does not free the route.

Do not use publication to test whether a number is available. Confirm the assignment and expected destination first. A valid base-number choice still does not prove the carrier, trunk, TLS or media path works.

4. Configure the browser channel and access boundaries

Control	Responsibility and boundary
Slug	An authored channel value. Do not treat it as a separately provisioned URL or substitute it for the endpoint ID required by the session API.
Advanced → Allowed Origins	The browser origin restriction for the generated endpoint. It is checked separately from API-key authorization.
Advanced → Allowed IPs	The network restriction for the generated endpoint. Check the source address seen by the integration, including any trusted proxy arrangement.
Voice Advanced → Egress Base Number	Outbound/transfer routing configuration where available; this does not grant transfer permission by itself.
Chat Advanced → Override Initial Node	An explicit starting-node override. Confirm that the node exists and is suitable for the intended text path.
Chat Response Mode, when present	An authored response setting. The editor shows this selector only when that field is already present; do not assume every newly added chat entry displays it or that selecting it changes the SDK session protocol.

Empty origin/IP lists do not impose those particular restrictions. They do not remove the need for authentication, correct team scope and an allowed session mode. Follow the integration guide's request path; never expose a team API key in browser code.

Voice and chat share the persisted browser endpoint

Reconciliation creates or updates one customer Browser endpoint for the app, with canonical slug browser. Voice and chat declarations do not create independent customer endpoint rows with independently enforced policies. The first browser declaration encountered during reconciliation supplies the shared endpoint's origin/IP and egress settings.

Keep the intended policy consistent across the app's browser declarations and verify the resulting endpoint used by the integration. Do not assume a restriction entered on a second channel overrides the first. Browser-action side flows can also require this endpoint even without a voice/chat entry.

5. Save and publish with route changes in mind

Save the draft, resolve readiness messages and use the application change procedure to review, test and publish deliberately. A phone entry without a base number blocks publication.

Publication reconciles endpoint rows with the selected flow definition as part of its database changes. In particular:

• Changed phone assignments update their routes; removed phone entries remove their associated orphan endpoint rows.
• Removing all browser entry surfaces unbinds the customer browser endpoint from that flow instead of necessarily deleting it. Browser actions may still constitute a browser surface.
• After database publication, runtime synchronization must still succeed. A synchronization error can leave committed database changes while live calls use earlier runtime configuration.

Endpoint reconciliation can also occur in other active-flow update paths used by tooling/testing. Do not rely on an unconditional “unpublished means no endpoint changes” rule. Use a designated test context, and inspect actual state if a test or update reports an error.

6. Verify the real destination

Start a new controlled interaction through the intended route after publication:

1. Confirm the app, team, endpoint ID or called number/extension, test time and intended published version.
2. For phone, dial the actual test destination and verify the selected flow and result. A browser test cannot establish phone routing or carrier behavior.
3. For browser, use the integration's actual endpoint ID and session mode from the approved origin/network. Confirm the intended flow result; for access-policy changes, also verify that an explicitly disallowed origin/network is rejected using an authorized test.
4. Use Review a conversation to open the matching record and check the expected path/output. If the route is wrong, use SIP diagnostics or the browser integration checks, as appropriate.

Success means the real destination reaches the intended behavior with the intended access restrictions. A visible entry chip, saved draft or existing endpoint ID alone is insufficient.

Recover from an incorrect change

If a number is reassigned incorrectly, access restrictions are wrong, or the wrong flow is reached, preserve the error and current state before making another change. Have the routing/integration owner confirm the intended endpoint and whether runtime synchronization completed.

Restore the correct entry configuration in a draft, review it and publish through the normal application procedure. Removing and re-adding a phone entry may affect its endpoint identity; do not assume an integration can keep using an old identifier after deletion. Check both the corrected route and any route that should no longer work.

If restoring an earlier flow definition, first preserve draft work you need. That restore replaces the draft; it does not by itself publish or prove runtime recovery. Escalate a remaining database/runtime mismatch to the operator with the app, route, version, time and redacted error rather than repeatedly toggling channels or broadening permissions.

Inspect an entry point

Select a phone, Web Voice or Web Chat entry-point object on the canvas. The panel is titled Endpoint, but edits the flow's authored entry-point configuration; it is not an independent endpoint database editor. Endpoint Type is descriptive, not a type-changing dropdown. Close dismisses the panel without discarding edits. Delete removes that entry point from the working definition and repacks the entry-point layout; it does not make a reversible hide-only change.

Changes are recompiled into the working flow. Follow the application Save/test/publish lifecycle and endpoint reconciliation rules before claiming live activation. An active-flow edit can also reconcile outside publication; draft/live distinction still matters.

Phone fields

Control	Behavior
Base Number	Selects a number available to this app's team. Changing it clears the existing extension code, even if the replacement number also supports extensions.
Extension Code (3 digits)	Shown only when the selected number enables extensions. Input strips non-digits and retains at most three; server route validation requires the appropriate valid assigned route, including exactly three digits when extensions are required.
Phone Number (DID)	Optional authored DID override; empty removes it. It does not provision a number or bypass base-number/team ownership checks.
Egress Base Number	Appears only when the team has numbers with egress trunks. Select an available number or the None option. This is outbound-transfer configuration, not inbound ownership.

No audio wire-format control appears in this inspector. Do not infer one from schema support for audio configuration. Consult the provider/audio guide and operator transport policy before source-level overrides.

Web Voice and Web Chat fields

Both show Slug, with example placeholders webrtc and chat respectively. Empty text removes the authored value. These fields do not establish separate published endpoint URLs for each entry: the application uses its reconciled browser endpoint, and the first browser entry can supply shared endpoint policy.

Web Voice Advanced contains conditional Egress Base Number, Allowed Origins, and Allowed IPs / Ranges. Web Chat Advanced contains Override Initial Node, Allowed Origins and Allowed IPs / Ranges. The initial-node override is a node ID, not a prompt or endpoint identifier; confirm it exists and is valid for the channel.

Response Mode appears for Web Chat only when an existing responseMode property is defined. Options are JSON, Text Stream, Audio Stream and None (fire and forget). A missing field does not create this selector automatically. The UI options are authored configuration; they are not proof the selected SDK/session protocol implements every output combination. Use the browser integration's request/response contract.

Allowed Origins and Allowed IPs / Ranges are free-text chip lists; press Enter to add and remove a chip to remove a value. Removing the final chip clears that list. The UI helper advertises wildcard subdomains and CIDR ranges, but a chip is not validation or authentication. Verify the active session access-control path and the observed request origin/client IP. Empty entry-point lists do not bypass independent API credentials, entitlements or deployment gates. Avoid conflicting access lists on multiple browser entries because they share endpoint policy after reconciliation.

Verify edits and deletions

Test the published endpoint through the intended phone/browser path using a designated account/destination. Confirm expected flow, permissions and route. Removing a phone entry can delete its orphaned endpoint row during reconciliation. Removing browser voice/chat does not always delete the app's browser endpoint: action capability can retain a browser surface; otherwise its flow binding can be cleared. Removing one browser entry is not equivalent to deleting an independent endpoint for that entry. Preserve a known working definition and route inventory before making access or routing changes.