Setup and operations

Designing a JavaScript-Assisted Routing Integration

Client code may support navigation or embedding, but public JavaScript cannot safely hold API credentials or become the only decision authority.

Decide why JavaScript is needed

Identify the browser-only context or interaction that cannot be handled by redirect, reverse proxy, iframe, or the server integration. Avoid adding a client layer merely to reproduce a decision already available before HTML renders.

Keep trust on the server

Never place a DuckRoute API key or privileged decision endpoint secret in a public bundle. Treat query strings, browser storage, and DOM values as attacker-controlled inputs and validate any resulting navigation target.

Provide a non-script failure path

Define visible behavior for disabled JavaScript, blocked requests, slow networks, malformed responses, and unavailable dependencies. Do not leave a blank document while an unbounded client retry waits for a routing answer.

Preserve only necessary context

Handle campaign parameters, history, referrer transitions, and repeat visits deliberately. Prevent duplicate decisions caused by hydration, component remounts, or several event handlers responding to the same navigation.

Verify across browser states

Test fresh and returning profiles, mobile WebViews, blocked storage, script failure, back navigation, and both destination outcomes. Inspect the network and DuckRoute event record to confirm one understandable decision per intended request.

Related guides