Newsletter
Hand over the forty links you saved this week and get back a structured issue: grouped sections, short summaries and an order that reads well, instead of a flat list. It does the deciding-what-goes-where part. You pay per use, with no subscription.
Run it online
Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.
a full issue from your notes
The slow part of a newsletter is not the writing
Summarizing a single link is quick. The slow part is looking at forty saved tabs and deciding which five matter, how to group them and what order makes the issue readable instead of a dump. For a solo writer that triage eats an evening every week; for a small team it turns into a Friday-afternoon scramble. This tool takes the raw pile, whether links, headlines or brief notes, and returns it organized into sections with short summaries and a coherent order, so the mechanical part of grouping and summarizing is already done when you sit down to edit.
Curation is what readers subscribe for
The revival of the email newsletter is largely a curation story. Readers don't subscribe because they can't find the articles themselves, but because someone already filtered and grouped them into something worth ten minutes, and that judgment is what makes the next issue worth opening too. You can state the section preferences you want respected: a publication covering several beats can tag links by topic and get an issue already grouped into matching sections, and a content team can collect links in a shared document all week and build the issue once the collection window closes. The final read and the send remain yours.
Curation as the actual product
The email newsletter's revival as a format is largely a curation story — readers subscribe not because they can't find the individual articles themselves, but because someone already did the work of filtering and grouping them into something worth ten minutes. That editorial judgment, more than any individual sentence, is what makes an issue worth opening the next week too.
What you can do with it
Team curating from a shared pool
A content team collects links in a shared doc all week and generates the structured issue automatically once the collection window closes.
Multi-topic digest
A publication covering several beats sends links tagged by topic and gets an issue pre-grouped into sections matching those beats.
FAQ
Does it write full articles or just summarize links?
It structures and summarizes what you send — grouping links into sections with short summaries — rather than writing original long-form articles from scratch.
Can I control how sections are grouped?
Yes, pass any section preferences with your request and they're respected when the issue is structured.
How many links can I send in one batch?
There's no fixed cap baked into the format — send the pile you've collected, from a handful of links to a much larger batch, and it's organized into a readable issue.
What format is the output in?
A structured issue with sections and summaries in the order that makes editorial sense, ready to drop into your send tool with light final editing.
Does it send the newsletter to my subscribers?
No. It returns the structured issue as a draft, and the final read-through and the send stay with you. That keeps a person on the last check before anything reaches your readers.
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/text/newsletter \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}'const res = await fetch("https://api.kit.forhosting.com/text/newsletter", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "El informe trimestral cerró con 1,2 M€ de ingresos."
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/text/newsletter",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "El informe trimestral cerró con 1,2 M€ de ingresos."
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/text/newsletter", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/text/newsletter", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text": "El informe trimestral cerró con 1,2 M€ de ingresos."
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "text.newsletter",
"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.
Limits
max_tokens | 20000 |
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. |
422 | task_failed | The task failed after 3 retries. You are never charged for it. |
Technical notes
Hand this endpoint a raw list of links, headlines or notes you've collected over the week, and it comes back with a structured newsletter issue: grouped sections, short summaries, and a coherent order instead of a flat list of URLs. It exists for the part of newsletter production that isn't writing — it's deciding what goes where.
The part of newsletter work that eats the most time
Writing a single link's summary is fast; the slow part is looking at forty saved tabs and figuring out which five matter, how to group them, and what order makes the issue readable instead of a dump. This endpoint takes the raw pile — links, headlines, or brief notes — and returns it organized into sections with summaries, doing the editorial triage that usually eats an evening every week for a solo writer or a Friday-afternoon scramble for a small team.
What the request looks like
POST /text/newsletter with your collected links or notes and any section preferences you want respected. The task runs asynchronously: you get a task_id immediately, and the structured issue is delivered by signed webhook or a signed link valid for 24 hours, so it fits into a publishing pipeline that assembles the draft and only needs a human for the final read-through and send.
Curation as the actual product
Automating the structuring step doesn't replace that judgment entirely, but it removes the mechanical part of grouping and summarizing so a human editor's time goes into the calls that actually need taste.
Fitting into a publishing workflow
This is built for solo newsletter writers automating their weekly grind, content teams curating from a shared link pool, and platforms that let subscribers submit links for a community roundup. Because delivery is async and webhook-based, a publishing tool can trigger generation the moment link collection closes for the week and have a structured draft waiting before the editor sits down. Pricing is $0.003 per request plus $0.0135 per issue, billed only on a completed issue — failed generations retry automatically up to three times at no charge.
Integration use cases
Solo writer's weekly issue
A one-person newsletter drops forty saved links into the endpoint Friday morning and gets a sectioned draft back before lunch instead of spending the evening organizing it by hand.
Community link roundup
A platform where subscribers submit links themselves runs the batch through the endpoint to produce a coherent weekly roundup rather than a raw list of submissions.
Technical questions
Is the newsletter generator API free?
There's no free tier — free tiers get abused and slow everyone down. Access runs on a prepaid ForHosting KIT balance: top up from $10.00 (it never expires) and each request is charged at its published price, so a call with no balance returns HTTP 402. No subscription, no tokens, no invented credits, and a failed task is never charged.
How do I get the finished issue back?
By signed webhook, recommended for automated publishing pipelines, or a signed link valid for 24 hours if you'd rather retrieve it manually.
Can I generate multiple issues in parallel?
Yes — each call to /text/newsletter is an independent async task, so multiple newsletters or multiple weeks can be processed at once.
Are my submitted links stored afterward?
No — they're deleted after the retention window and never used for training; the endpoint's only purpose is producing your issue.