If you are not a developer, these names are just labels for parts of the stack. Short definitions:

Server (web server)

A computer on the internet that runs wpulse.org 24/7. When someone opens a page or submits a survey, their browser talks to this machine.

HTML

The language of web pages (structure, text, buttons). Your browser renders HTML into what you see on screen.

PHP

A programming language that runs on the server (not in the visitor’s browser). Wellness Pulse uses PHP to build pages, read form submissions, talk to the database, and send email. Files often end in .php (e.g. under api/).

API / endpoint

A URL on the server that accepts requests (often JSON) and returns data or success/error. “Backend” logic for the product usually lives here instead of in the visible HTML.

PostgreSQL

A database program (also called Postgres). It stores tables of institutions, surveys, responses, etc. PHP sends it SQL queries to insert, update, or read rows. Think of it as the structured filing cabinet the app reads and writes all day.

Database / table / row

The database holds many tables (like spreadsheets). Each row is one record (e.g. one survey response). Columns are fields (date, score, hashes, …).

JSON

A simple text format for structured data between browser and server (lists, keys, values). Many API responses and survey payloads are JSON.

HTTP / HTTPS

The protocol browsers use to request pages and APIs. Status codes like 429 mean “too many requests” or “rate limited.”

Cron

The server’s scheduler. It runs commands at set times (e.g. daily trial reminders). Those commands often invoke PHP files in the scripts/ folder.

SMTP

The standard way a server sends outbound email (e.g. outreach or notifications) through a mail provider.

SHA-256 (hashing)

A one-way “fingerprint” of a piece of text (e.g. IP or browser string). Same input → same fingerprint; you cannot realistically reconstruct the original from the fingerprint alone. Used for duplicate-survey checks. see the dedicated FAQ below.

The idea in kid-sized words: We want to stop someone from clicking “submit” ten times on the same survey in one day. We also do not want to keep a notebook of everyone’s private address book. So we use a math blender that turns two clues into two fingerprints. Fingerprints let us say “this looks like the same visitor again” without writing down the original clues.

   ┌─────────────────────┐     ┌─────────────────────┐
   │  Clue A (IP-ish)    │     │  Clue B (browser)   │
   └──────────┬──────────┘     └──────────┬──────────┘
              │                           │
              └───────────┬───────────────┘
                          ▼
              ┌───────────────────────┐
              │   SHA-256 “blender”    │  ← one-way math: easy forward,
              │   (always same size)   │    practically impossible backward
              └───────────┬───────────┘
                          ▼
              ┌───────────────────────┐
              │  Two fingerprint codes │  ← saved on the response row
              └───────────────────────┘

Why people call it “one-way”: Imagine you blended fruit into a smoothie. You can taste that it’s a smoothie, but you can’t unpour the blender and get the exact same whole fruits back. SHA-256 is like that: we can match “same smoothie again?” but we don’t keep the fruit bowl in the database for this check.

Same computer, different browser? Usually the User-Agent string changes, so user_agent_hash is different even if ip_hash is the same. The duplicate check requires both hashes to match, so we often cannot treat that as the “same device” for this rule, and the person could submit again the same day. That is a known limit of IP+UA fingerprinting (not a full device login).