NaNoWriMo daily word count

Negative targets, negative elapsed days, and negative words written are rejected as invalid_input rather than silently producing a backwards or imaginary pace.

What the NaNoWriMo daily quota actually is

The official NaNoWriMo calendar is thirty days long. A writer who starts with a fifty-thousand-word target and zero words on day zero therefore needs fifty thousand divided by thirty, which is one thousand six hundred sixty-six and two thirds words per day, conventionally raised to one thousand six hundred sixty-seven whole words so the integer total still finishes the draft. After ten days with twelve thousand words on the page, remaining words are thirty-eight thousand and remaining days are twenty, so the quota is exactly one thousand nine hundred words per day. That is the entire algorithm: remaining_words equals the greater of zero and target_words minus words_written; remaining_days equals thirty minus days_elapsed; words_per_day is remaining_words divided by remaining_days, then raised to the next whole word when the quotient is not already an integer. When remaining_words is already zero, the quota is zero: the goal is met and no further daily target is required. When remaining_days is zero and words still remain, the challenge window has closed with the draft unfinished, which this endpoint reports as invalid_input rather than dividing by zero or inventing a last-day miracle. The calculator does not invent a calendar date, does not call a clock, and does not assume that today is November; you pass days_elapsed as a number so a rehearsal in July, a classroom simulation, and a live November dash all use the same contract. Catching up after a slow week is simply a larger remaining_words over fewer remaining_days, which is why the quota rises when you fall behind and falls when you get ahead.

Input contract, response shape, and error behaviour

Failed validation is not billed. POST a JSON body with three required finite numbers: target_words, the novel word goal (classically fifty thousand, but any non-negative finite total is accepted); days_elapsed, how many of the thirty challenge days have already passed; and words_written, the running total already on the page. Aliases target, word_goal, and goal are accepted for the first field; elapsed, elapsed_days, and days for the second; written, current, and word_count for the third. Each field may arrive as a JSON number or as a numeric string. Missing fields, empty strings, and non-finite values fail with invalid_input naming the field. Any negative input fails with invalid_input: NaNoWriMo cannot owe you negative words, cannot un-elapse days, and cannot un-write a draft. days_elapsed cannot exceed thirty, the published length of the challenge; a value greater than thirty would make remaining_days negative, which is the same class of error as a negative input. On success the body echoes the three inputs, reports challenge_days as thirty, remaining_words, remaining_days, words_per_day as the integer daily quota, words_per_day_exact as the unrounded quotient, already_finished as a boolean, and a formula string restating the identity. Example: target_words fifty thousand, days_elapsed ten, words_written twelve thousand yields remaining_words thirty-eight thousand, remaining_days twenty, and words_per_day one thousand nine hundred. The browser tool is free; successful API calls use prepaid KIT balance at $0.002 per item.

Where a NaNoWriMo words-per-day API earns its keep

Writing groups run a shared NaNoWriMo dashboard so every member pastes a target, elapsed days, and current word count and sees a single comparable daily quota instead of five incompatible spreadsheet formulas. Editors coaching a thirty-day sprint can re-run the calculator when a client raises the target from fifty thousand to seventy thousand without rewriting a custom script. Classroom novel units use the same endpoint as a teaching tool: students who start late see a higher remaining-days quotient and learn, numerically, why catching up is harder than starting on day one with a blank file. Personal trackers and habit apps call the API after each session so the home screen shows tomorrow's words_per_day without embedding calendar math that drifts when someone treats November as thirty-one days. Automation that already stores a word count from a progress form should call this endpoint rather than hard-coding fifty thousand divided by thirty, which is only correct on the morning of day one with an empty manuscript. Keep days_elapsed in the closed interval from zero through thirty, keep the other two fields non-negative, and you get a reproducible NaNoWriMo pace without standing up a writing-platform integration of your own.