Average propensity to consume (APC)
Spend 36,000 out of a disposable income of 45,000 and your average propensity to consume is 0.8: eighty cents of every after-tax dollar went to consumption. Below one means saving; above one means drawing on savings or debt. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Consumption
- 36,000
- Disposable income
- 45,000
- Apc
- 0.8
The average propensity to consume tells you what share of disposable income is actually spent rather than saved. The result is rounded to a precision you choose, validated against the failure modes that matter, and computed by the same code that runs free on this page, so what you test by hand is exactly what your pipeline receives at scale.
What the average propensity to consume measures
The average propensity to consume is one of the oldest ratios in macroeconomics: total consumption divided by total disposable income. A value of 0.8 means that eighty cents of every after-tax dollar received during the period went to consumption, with the remaining twenty cents going to saving or debt repayment.
Because it is a pure ratio, APC lets you compare spending behavior across households of different sizes, regions with different price levels, or the same economy in different years — as long as both inputs describe the same population and the same period. An APC below one indicates net saving; an APC above one means the period's consumption exceeded income, financed by drawing down savings or borrowing, which is common for students, retirees and households in a temporary income dip.
Keynes introduced the concept to argue that APC tends to fall as income rises, which is why the ratio still anchors consumption functions, fiscal multipliers and household-finance research today. Used at the micro level, it answers a plainer question with the same arithmetic: of the money this person or segment actually had available, how much went back out the door as spending?
How the ratio is computed and validated
Both inputs must be finite numbers expressed in the same currency and units; numeric strings such as "36000" are coerced so form and query-string input works without pre-processing. Consumption may be zero — a period with no spending is a valid observation — but it may not be negative, since negative consumption has no economic meaning at this level of aggregation.
The rejected call is never billed, so bad source data fails cheap and loud at the boundary of your pipeline rather than silently distorting every downstream aggregate that would have consumed the ratio.
What you can do with it
Compare saving behavior across cohorts
Compute APC per household segment from survey aggregates to see which groups spend more of their disposable income.
Normalize data for a savings-rate dashboard
Turn raw consumption and income figures into a single comparable ratio before charting trends over time.
Grade economics exercises deterministically
Give every student submission the same byte-identical APC result, with a configurable rounding precision.
FAQ
What formula is used?
APC = total consumption divided by total disposable income, rounded to the requested precision (default 4 decimal places).
What does an APC above 1 mean?
Consumption exceeded disposable income in the period — the difference was financed by savings or borrowing.
Why was my request rejected?
Disposable income must be greater than zero and consumption cannot be negative.
Can I pass numbers as strings?
Yes. Numeric strings like "36000" are coerced. Values that do not parse as finite numbers are rejected.
Is any data stored?
No. The two inputs are divided and discarded; only the ratio is returned.
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
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/fin/apc \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"consumption":36000,"disposable_income":45000}'const res = await fetch("https://api.kit.forhosting.com/fin/apc", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"consumption": 36000,
"disposable_income": 45000
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/fin/apc",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"consumption": 36000,
"disposable_income": 45000
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/fin/apc", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"consumption":36000,"disposable_income":45000}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"consumption":36000,"disposable_income":45000}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/fin/apc", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"consumption": 36000,
"disposable_income": 45000
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "fin.apc",
"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
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
Send total consumption and total disposable income for the same period, and this API returns the APC ratio in one deterministic call — the exact normalization economists, analysts and students reach for before comparing households, regions or years.
How the ratio is computed and validated
The endpoint performs a single, fully deterministic division: APC = consumption / disposable_income, rounded to the number of decimal places you request (four by default, adjustable from zero to six). Disposable income must be strictly greater than zero: a zero or negative denominator would make the ratio undefined or misleading, so the request is rejected with an invalid_input error and no charge instead of returning a plausible-looking number.
Where APC fits in real analysis
Teams computing APC usually need it as a repeatable step inside a larger pipeline rather than as a one-off spreadsheet cell. Common setups include feeding household survey aggregates into a savings-rate dashboard, normalizing consumption data before comparing cohorts, and teaching or grading environments where the same formula must produce byte-identical results on every machine. Because the same code runs free in your browser on this page and in the paid API, you can verify a pair of numbers by hand and only pay — $0.002 per request — once you automate the call. The API stores nothing: the two inputs are divided and discarded, and only the ratio is returned, which keeps the step safe to insert into compliance-sensitive reporting flows. Because the call is stateless and idempotent, it also caches well: identical input pairs always yield the identical ratio, so repeated runs in a nightly batch or a retry after a network failure never drift.
Technical questions
What does it cost?
$0.002 per request. It is also free to run in your browser on this page.