Spensara Spensara Knowledge Base & Documentation Repository

Repository Docs & Knowledge Base

Consolidated Spensara documentation repository (722 Markdown & architecture documents in ../repository)
Built Word Documents (.docx): Spensara Overview (.docx) Capability Assessment (.docx) Brink POS Ingestion Analysis (.docx) The Borg Ingestion Architecture (.docx)

Implementation Specs (157)

Detailed engineering and feature implementation specifications.
implementation-specs/specs/CustomerCredentialCustomHeaders/TASK2.2.md 2,474 bytes · Updated Oct 23, 2026 10:44 AM EDT
Raw File

TASK 2.2: Propagate custom headers through Brink connection resolution and facade transport

Summary

Attach persisted custom headers to outbound Brink facade requests.

This task completes the runtime value of the slice by taking the newly stored credential metadata and sending it on every relevant downstream request.

Dependencies

Files to Modify

Runtime transport

  • backend/integrations/Kds.Ai.Integrations.BrinkPos/Services/Facade/Clients/BrinkAuthHeaderScopeFactory.cs

Supporting models or callers only if needed

  • backend/integrations/Kds.Ai.Integrations.BrinkPos/Services/Facade/Clients/BrinkTransportRequest.cs
  • backend/integrations/Kds.Ai.Integrations.BrinkPos/Services/Facade/Clients/BrinkSoapExecutor.cs
  • backend/integrations/Kds.Ai.Integrations.BrinkPos/Services/Facade/BrinkRawClient.cs
  • backend/integrations/Kds.Ai.Integrations.BrinkPos/Services/Facade/BrinkPosFacade.cs

Required Changes

Header emission rule

Whenever a BrinkConnectionDefinition contains custom headers, the request-construction path should add them to the outgoing HttpRequestMessage.

That is in addition to:

  • SOAPAction,
  • current XML content headers,
  • current AccessToken and LocationToken handling when UseHeaderAuthentication is enabled.

Conflict rule

Document and implement what happens if a configured custom header collides with an existing framework-managed header such as:

  • AccessToken,
  • LocationToken,
  • SOAPAction,
  • Content-Type.

Recommended rule for this slice:

  • framework-managed headers win,
  • custom headers with reserved names are rejected during validation rather than silently overriding transport behavior.

Logging rule

Do not log raw custom header values.

If request diagnostics mention custom headers at all, they should mention only names or counts, not secret values.

Acceptance Criteria

  • [ ] Every Brink facade request includes configured custom headers
  • [ ] Existing auth-header behavior remains unchanged
  • [ ] Reserved-header collisions are handled explicitly and safely
  • [ ] No logging path exposes secret custom header values

Notes

  • Prefer adding the headers in one place, ideally the existing request factory, rather than distributing the behavior across multiple clients.
  • Keep the runtime behavior deterministic across Settings, Settings2, Sales2, and Kitchen clients because they all share the same transport path.