E-FACTS — E-receipt management companyE-FACTS — E-receipt management company
Product

Surfaces map

Which E-FACTS product owns which job — iOS, website, docs, backend, portal

Surfaces map

E-FACTS is a multi-surface system. Confusion usually comes from putting a job on the wrong surface.

Map

SurfaceRepo / homeAudienceOwns
Marketing websiteefacts-websiteProspects, retailers, pressBrand story, public entry points
Consumer iOS appefacts-iosappShoppersPrimary product IA (4 tabs)
Backend / APIsefacts-backendClients + opsAuth, receipts, warranties, wallet bind, shopper services
Internal docsefacts-dev (this site)CompanyHandbook at planned dev.efacts.ca
Portal / loginrelated portal workRetail / internalAccess and session boundaries separate from public marketing

Historical reference: E-Facts V.1 (earlier backend + iOS) — use for archaeology, not for greenfield defaults.

Ownership rules

If the work is…Put it in…
Shopper daily path (tabs, receipt detail, analysis)iOS + backend APIs
Public narrative, SEO, retailer pitchWebsite
Company process, design tokens, engineering standardsDocs (efacts-dev)
Tokens, schemas, bind validation, SSE streamsBackend
Retail ops console / internal adminPortal (not consumer tabs)

Cross-surface contracts

  • Auth: Backend issues JWTs; iOS stores access tokens in Keychain; Google sign-in verifies id_token server-side.
  • Money: Integer cents (Int64 / integer) end-to-end — never floating currency in APIs.
  • JSON: Backend responses use snake_case; clients map explicitly.
  • Brand: Tokens and contrast rules live in docs/Design.md + Design language.

Domains

DomainSurface
efacts.caMarketing
dev.efacts.caInternal docs
API hosts (per env)Backend — see each repo’s env docs

On this page