Do not put a private credential into a public website to avoid a backend

A small feature can introduce an operating responsibility the project is not prepared to accept. Before promising a customer-specific price display, establish where the authoritative price comes from and which authentication method the provider supports.

This fictional decision concerns a supplier whose website must remain on an approved static-only hosting arrangement. The owner wants returning customers to see account-specific quotes. The chosen provider offers a private server-to-server pricing interface and a separate hosted customer service.

Inspect the two constraints together

The provider's reviewed fixture contract requires a confidential credential for the pricing API. It does not offer a public-token or browser-authorisation flow for this particular endpoint. The credential can access more than one customer's pricing records.

The supplier's approved website scope contains no backend capable of holding that secret and enforcing customer access. Adding one would require a hosting, account-ownership and maintenance decision outside the current agreement.

Either fact alone is incomplete. Static pages can call suitable public interfaces, and some providers support browser-oriented authorisation. This proposal fails because this endpoint and this approved architecture do not fit together.

Reject the apparent shortcut

Placing the credential in a JavaScript file, a hidden input or a public configuration value would distribute it to the browser. Minifying the file or hiding the control would not turn it into a server secret.

The team therefore rejects the direct browser integration under the present scope. It does not ask the owner to accept a warning beside the same unsafe design. Nor does it assume that a proxy can be added without someone owning its access checks, hosting and ongoing operation.

This decision concerns the inspected private credential. It is not a claim that every token visible in a browser is secret or that all client-side integrations are inappropriate. The provider's actual credential model determines the boundary.

Demonstrate the supported alternative

The provider's hosted customer service supports authenticated account quotes under the supplier's reviewed arrangement. The team tests that route with fictional customer A and a distinct fictional customer B in the provider's supported test environment.

Customer A follows the clearly labelled link, signs in through the provider and opens the quote assigned to A. B's quote is not available through A's account. An unauthenticated visit reaches the provider's sign-in route rather than exposing either quote. The public website continues to show the approved general catalogue without private prices.

No confidential pricing credential appears in the public site assets or link. The customer understands that the quote task continues on the provider's service. The supplier records who administers the accounts and where a customer should ask for help.

Make the narrower scope a real choice

The owner accepts the hosted route for the first release and defers the embedded account-price feature. The proposal includes the link wording, customer explanation and support responsibility. It does not describe the hosted service as though it were a newly built private area on the supplier's site.

The decision has a cost in convenience: the customer moves to another service and uses its account journey. That tradeoff is explicit. The team has demonstrated the bounded quote task rather than assuming an external link will be sufficient for every customer requirement.

Name what would justify reconsideration

The embedded feature could be reassessed if the provider introduces a suitable supported browser flow or the supplier approves a backend with clear security and operating ownership. Either change would need a new assessment of identity, permissions, data handling, provider terms and acceptance.

A request to make the current page look more seamless does not supply those missing capabilities. The constraint is architectural and operational, not a lack of visual polish.

Carry the decision into maintenance

The handover records why the browser integration was deferred, the accepted hosted destination and the account owner. This helps a later editor avoid replacing the link with an unofficial script copied from a demonstration.

Review the destination and its customer task when the provider changes its service. If it stops meeting the requirement, the organisation needs another supported plan rather than an unreviewed credential workaround.

The integration service can assess the actual interface and architecture. Use the decision kit to bring the desired customer task and the constraints that the first release must respect.