ForHosting KIT · Science

Water demand calculator

Ten thousand people using 150 liters each demand 1,500,000 liters a day and 547,500,000 liters a year. Enter a population and a per-person figure to size a supply or compare a town with a benchmark. Free in your browser.

Free
Runs in your browser
No sign-up
Your data stays on your device

Run — free How it works & API

Use it from WebAPIEmailTelegramApp soon

Worked example

If you enter

Population: 10,000
Per capita liters: 150

You get

Daily liters: 1,500,000
Annual liters: 547,500,000
Days in year: 365

Municipal and community water demand is the volume a service area will withdraw if you know how many people live there and how many liters each person uses in a day. Utilities, city planners, environmental consultants, and students of water resources need that product as both a daily total and an annual total so they can size treatment plants, compare a town against a published liters-per-capita-per-day benchmark, and place a year of withdrawals next to a reservoir budget. This water demand calculator accepts a population size and a daily per-capita consumption in liters, multiplies them for daily demand, then multiplies the daily total by 365 for annual demand, both returned in liters. Zero is allowed and returns zero liters, because an empty service area or a zero-consumption scenario really does demand nothing.

How water demand is computed from population and LPCD

At first order, community water demand is not a weather model or a pipe-network simulation: it is the product of two quantities a planner already has or can assume. Population is the number of people served — a census count, a design-horizon projection, a refugee-camp occupancy, or the residents of a housing estate. Daily per-capita consumption is the liters each of those people uses in one day, written LPCD in water-engineering tables.

Published figures typically run from about fifty liters per person per day in a tightly rationed rural supply, through one hundred to two hundred in many urban networks, to three hundred or more where outdoor irrigation and leaking distribution dominate. Daily demand in liters equals population times that per-capita figure. Annual demand equals the daily total times 365, the civil day-count used for year-ahead reservoir and treatment-plant budgets.

Ten thousand people at one hundred fifty liters each therefore demand one million five hundred thousand liters in a day and five hundred forty-seven million five hundred thousand liters in a year. A quarter of a million people at one hundred eighty point five liters each demand forty-five million one hundred twenty-five thousand liters per day. The method does not add unaccounted-for water, industrial block loads, seasonal peaking factors, or fire-flow reserves; those belong in a full water-master-plan model that you can layer on after you have this base.

Change either input and both totals move in lockstep. This page is not a personal drinking-water intake calculator, a tank-capacity page, or a dripping-faucet waste page: those answer how much one body should drink, how much a vessel holds, or how much a leak has already wasted — not how much a population will withdraw from the network.

What to enter: people and liters per person

Fractional population is allowed so a mid-year estimate such as 12500.5 does not have to be rounded first, and fractional LPCD is allowed so a measured 137.4 liters per person per day is sent as-is. Missing fields, empty strings, booleans, objects, and tokens that are not plain decimal or scientific numbers fail the same way. Zero is accepted and returns zero liters, because an empty service area or a zero-consumption scenario really does demand no water.

Numbers are rounded to twelve decimal places so goldens and clients compare byte-for-byte across runtimes. If the product overflows to Infinity the task fails rather than returning a non-finite volume. The year is the exact civil 365-day year used in screening demand, not 365.25 and not a leap-year calendar, so an annual total is reproducible from the same inputs on every machine.

What you can do with it

Municipal screening demand

Turn a census population and a published LPCD into daily and annual liters you can put next to a treatment-plant rating or a reservoir budget.

FAQ

How is population water demand calculated?

Daily demand in liters equals population times daily per-capita consumption in liters. Annual demand equals that daily total times 365. Ten thousand people at 150 liters each give 1,500,000 liters per day and 547,500,000 liters per year.

What LPCD value should I use?

Use a measured or published liters-per-capita-per-day figure for the service area. Typical screening values sit near 50 L in a tightly rationed rural supply, 100–200 L in many urban networks, and 300 L or more where irrigation and leakage dominate. The calculator does not guess LPCD.

Why is the year 365 days and not 365.25?

Screening demand uses the civil 365-day year so the annual total is reproducible and matches year-ahead utility budgets. Leap-year and 365.25 mean-year adjustments belong in a calendar model, not in this product.

What happens if population or per-capita liters is negative?

A negative population or a negative per-capita rate is not a physical demand. Zero is allowed and returns zero liters. Invalid input is not billed.

Is this the same as personal water intake, and what does it cost?

No. This page estimates how much a population will withdraw, not how much one person should drink. The browser tool is free.

Related tools

For developers — API access

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

API endpoint

POSThttps://api.kit.forhosting.com/eco/water-demand

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.

Call it from your stack

curl -X POST https://api.kit.forhosting.com/eco/water-demand \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"population":10000,"per_capita_liters":150}'

const res = await fetch("https://api.kit.forhosting.com/eco/water-demand", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "population": 10000,
    "per_capita_liters": 150
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/eco/water-demand",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "population": 10000,
    "per_capita_liters": 150
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/eco/water-demand", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"population":10000,"per_capita_liters":150}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"population":10000,"per_capita_liters":150}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/eco/water-demand", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Example request

{
  "population": 10000,
  "per_capita_liters": 150
}

Example response

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "eco.water_demand",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Pricing

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

Errors

HTTP	Code	Meaning
`401`	`unauthorized`	Missing or invalid API key.
`402`	`insufficient_balance`	Your balance doesn't cover the task price.
`404`	`unknown_type`	That task type doesn't exist.
`429`	`rate_limited`	Too many requests. Use the webhook instead of polling.

Technical notes

Negative population or negative per-capita use fails with invalid_input instead of inventing a withdrawal.

Inputs, units, aliases and error behaviour

Send a JSON object with two required finite numbers: population, the number of people in the service area; and per_capita_liters, the daily consumption of each person in liters. Each field also accepts a numeric string and a short list of aliases (pop, people, inhabitants, n, lpcd, liters_per_capita, daily_per_capita, consumption, per_capita) so spreadsheets and forms do not have to rename columns. Any negative value is rejected: a negative population or a negative per-capita rate is not a physical demand, so the task fails with invalid_input that names the field. On success the response echoes the resolved population and per_capita_liters, then reports daily_liters as population times LPCD, annual_liters as daily_liters times 365, days_in_year always equal to 365, a compact formula string, and the method label population_times_lpcd_times_365. There is no network lookup, no random draw, and no dependence on the current date or on leap-year calendars: the same two numbers always produce the same JSON.

Where a water-demand API earns its keep

Utilities and municipal engineers use a deterministic water demand calculator to turn a census population and a published or measured LPCD into daily and annual liters they can put next to a treatment-plant rating, instead of quoting a slogan about how much a city uses. Climate and conservation campaigns that ask visitors to compare their town against a one-hundred-liter LPCD target can send the same two numbers the visitor already typed and show the annual withdrawal without inventing a consumption rate. Failed validation does not consume balance. Keep requests small, pin the rounded fields in tests, and you get a reproducible demand product without standing up a billing integration of your own. Consultants who already log service-area populations can post one task per community and store daily_liters and annual_liters beside the area identifier without opening a spreadsheet of 365-day factors. If you later need a cost in currency, multiply liters by your local tariff; this endpoint stops at volume on purpose. If you later need peak-hour or maximum-day demand, apply your own peaking factor to daily_liters; the base product stays auditable and unchanged.

Integration use cases

Consultant service-area batches

Post one task per community with the logged population and per-capita liters, then store daily_liters and annual_liters beside the area identifier.

Classroom and campaign widgets

Let visitors type a population and an LPCD target and see daily and annual demand on a live tool that matches the API byte-for-byte.

Read the full KIT documentation →

Run — free