Skip to content

Security requirements for integrations

Every connector, TechTur's own included, must meet these before production access is approved.

Credentials

  • Store client secrets, refresh tokens, API keys and webhook secrets in a secrets manager or encrypted at rest. Never in source control, front-end code, mobile apps, logs or URLs.
  • Use client credentials only from servers. Browser and mobile apps use authorization code + PKCE and never hold the client secret.
  • Rotate the client secret if it may have leaked (console → Rotate secret); the old one stops working immediately.

Tenancy

  • Treat businessId as data the API checks, not proof of anything. Never let one of your customers choose another customer's businessId; derive it from your own server-side mapping.
  • Store one token pair per business; never share a token across businesses.

Identity

  • Mint launch tickets only for a user your platform authenticated in the current request, with the role they actually hold.
  • Never assume two accounts are the same person because their emails match.

Data

  • Request the fewest scopes you need. Ask only for customers:* if you truly process customer data, and handle it under POPIA (purpose limitation, minimality, security safeguards, retention).
  • Never send card numbers, CVVs or PINs to POS. Record only provider references and, at most, the last four digits.

Webhooks

  • Verify every signature against the raw body; reject stale timestamps; de-duplicate on event id.
  • Serve your endpoint over HTTPS with a valid certificate.

Writes

  • Use idempotency keys / externalRef so retries cannot double-charge, double-deduct or duplicate.
  • Respect data ownership; never overwrite POS-owned fields by other means.

Review checklist (live approval)

  1. Manifest validates and matches the scopes requested.
  2. Sandbox run shows: product sync, order submission with retry, webhook verification, disconnect handling.
  3. No secrets in the repository (git log -p | grep -E "tps_(cs|sk|rt)_live" is empty).
  4. Error handling follows Error handling.