Can Kagi's Summarizer API receive text without a public URL?

Definition: Yes. Kagi's Universal Summarizer API accepts a text string as the document input and treats text and url as exclusive fields. A request can therefore carry source text without a document URL, subject to Kagi's request format and size limit.

Key facts

• Kagi exposes document summarization at GET/POST /summarize; its documentation describes the endpoint as accepting a URL or passed text. Kagi's Universal Summarizer documentation
• The url field is a required URL alternative, and the text field is a required string alternative. The same documentation marks each as exclusive with the other.
• Kagi says that one of these two fields must be passed. Sending a request with neither field falls outside the documented input contract.
• Parameters can be sent as URL parameters with GET, as a JSON body with POST, or as an x-www-form-urlencoded body with POST.
• Kagi recommends POST for the text parameter to avoid URL length limits, and limits the total request size to 1MB.

How do the text and url inputs differ?

The API models the source as one of two alternatives. url identifies a document for Kagi to retrieve, while text supplies the text to summarize as a string. The endpoint description calls both forms document summarization, so a public page is unnecessary when the source is supplied through text.

The fields are mutually exclusive in Kagi's parameter table and in its notes. The documented rule is to pass one or the other. The page does not specify the server response when both fields are included, so this entry treats the exclusive-input rule as the complete supported contract.

Why is POST the practical method for raw text?

Kagi's documentation lists three parameter encodings: URL parameters with GET, JSON with POST, and form encoding with POST. It specifically recommends POST for text because URL length limits can constrain a text value.

HTTP Semantics, the IETF specification for HTTP methods, describes GET as a request to transfer a current representation for a target resource. It says that content received in a GET request has no generally defined semantics. The same specification describes POST as asking the target resource to process the representation enclosed in the request and gives providing a block of data to a data-handling process as one example. That method model matches Kagi's recommendation for sending source text in a request body. HTTP Semantics

What should a text-only request contain?

The API's JSON-body form can carry text without url:

curl -X POST https://kagi.com/api/v0/summarize \
  -H "Content-Type: application/json" \
  -H "Authorization: Bot $TOKEN" \
  -d '{"text":"Text to summarize"}'

The endpoint also documents optional fields named engine, summary_type, target_language, and cache. The raw input remains the text string; these fields control processing options described by the same API page. The request still has to remain within Kagi's total 1MB request-size limit.

What does the API return?

Kagi says that the endpoint returns a Summarization Object. Its documented fields are output, described as the summarization output, and tokens, described as the amount of tokens processed. The input choice changes how the source is supplied; it does not change the documented response object.

Related terms

• Kagi Universal Summarizer
• Kagi Assistant
• Answer engine

FAQ

Can a text-only request omit url?

Yes. Pass the source in the text field and omit url; Kagi documents the two fields as exclusive and requires one or the other.

Should raw text use GET or POST?

Use POST with a JSON or form body. Kagi recommends POST for text because URL length limits can affect URL parameters.

Is there a separate text-only size limit?

Kagi documents a total request-size limit of 1MB. The page does not state a separate limit specifically for the text field.

Sources

1. Kagi, "Universal Summarizer", n.d.
2. IETF, "HTTP Semantics", June 2022

---

Check how a page reads to answer engines. Open the GEO score analyzer