MakeQuestions API by Karson AI

Changelog

New updates and improvements to the MakeQuestions API and Karson AI API. Each release notes breaking changes, additions, and migration tips.

v3.3.0

Added file attachments (images and documents) as the preferred way to send files, and raised request limits.

Added

  • attachments on POST /generate-questions and POST /follow-up: an array of { "url", "mime_type", "name"? } with public HTTPS URLs. Images (image/jpeg, image/png, image/gif, image/webp) are sent as vision input; documents (application/pdf, .doc, .docx, text/plain) are read directly as source material. Up to 1,500 images and 50 documents per request; URLs must be HTTPS and ≤ 8,192 chars. Prefer attachments over legacy image_urls.

Changed

  • Rate limit raised to 1,000 requests per minute per API key.
  • Vision input limits raised: up to 1,500 image URLs, each up to 8,192 characters (legacy image_urls).

Why

  • Send PDFs, Word docs, and text files directly as question source material, instead of pre-extracting text.
  • Higher limits support batch and document-heavy workloads.

v3.2.0

Renamed the follow-up request field previous_response_id to response_id so request and response use the same name for the same handle. Breaking change for any client that calls POST /follow-up.

Breaking Changes

  • POST /follow-up now expects response_id in the request body. previous_response_id is no longer accepted and (because extra="forbid") returns 422.
  • Update payloads from { "previous_response_id": "resp_abc123", ... } to { "response_id": "resp_abc123", ... }.
  • Response bodies and SSE done events are unchanged — they already used response_id.

Why

  • One name for the continuation handle on both ends of a turn — copy a response_id straight from the last response into the next request.
  • Removes the long-standing wording mismatch in docs and SDKs.

v3.1.0

Simplified the request contract: question_config is now required and the"mixed" question type is gone. Callers declare exactly which concrete types they want and optionally how many of each.

Breaking Changes

  • question_config is required on POST /generate-questions and on POST /follow-up with request_type: "more-questions". Requests without it return 422.
  • type_counts must be a non-empty map of concrete question types. {}, all-0 maps, unknown keys, and the old "mixed" key are all rejected with 422. (A 0 on an individual key is silently dropped — equivalent to omitting the key — as long as at least one entry remains.)
  • No more implicit “open mix” default. Omit a type to exclude it; use null per-type to let the model decide that type’s count (the server guarantees at least 1 of every requested type).
  • Playground no longer offers a “Mixed” type option — pick one or more concrete types.

Why

  • Smaller system prompts — documentation for unused types is no longer injected.
  • Predictable count enforcement — the validator and agentic filler always know exactly which types to target.
  • Simpler mental model — one required, non-empty map with clear per-key semantics (int = exact count, null = model decides quantity with a guaranteed minimum of 1 of that type, omitted = disabled).

v2.9.1

Added optional vision input via image_urls on the generation endpoints.

Added

  • Optional image_urls on POST /generate-questions and POST /follow-up (all request_type values). Image URLs are forwarded to the model alongside the text input on the same turn.

Validation

  • HTTPS URLs only.
  • Max 5 URLs per request; each URL ≤ 2,048 characters.
  • Duplicates are removed server-side.

v2.9.0

Generation requests adopt question_config. The legacy top-level shape (question_type_counts, top-level difficulty, allowed_types) is no longer accepted on POST /generate-questions.

Breaking Changes

  • Top-level question_type_counts, difficulty, and allowed_types are removed from POST /generate-questions. Use question_config with a type_counts map and optional difficulty.
  • Same rules apply to POST /follow-up with request_type: "more-questions".
  • Do not send "mixed" as a difficulty value — use null or omit.

Behavior

  • Omitting question_config (or sending null) used the default open mix at this release. This was tightened to a hard requirement in v3.1.0.

v2.8.1

Streaming inline-explanation now emits text deltas as they arrive, so UIs can render the explanation character-by-character instead of waiting for the full payload.

Added

  • New SSE event explanation_text on streaming POST /follow-up with request_type: "inline-explanation". Data shape: { "text": "<delta>" }.
  • The existing explanation event still fires once after streaming completes with the full text — backward-compatible for clients that only consume the final payload.

Fixed

  • Analytics: delivery_mode is now populated for inline-explanation requests (was previously NULL); failed inline-explanation and chat requests are now persisted with error metadata.

v2.8.0

Expanded POST /follow-up to three request types — more-questions,inline-explanation, and chat — enabling conversational interactions on top of question generation.

Added

  • request_type: "inline-explanation" — concise explanation for one question. Put the question text in input; question_type_counts is ignored.
  • request_type: "chat" — free-form tutoring chat over the thread; always streamed via SSE.
  • response_id returned on every /follow-up response (and on the SSE done event) for chaining further turns. (At this release the corresponding request field was still named previous_response_id — see v3.2.0.)

Validation

  • more-questions: question_type_counts required; previous_response_id optional.
  • inline-explanation: previous_response_id and input required; question_type_counts ignored.
  • chat: previous_response_id and input required; always streamed.

v2.7.0

Consolidated streaming endpoints into a single endpoint with a streaming parameter.

Breaking Changes

  • /generate-questions/stream-by-question removed — Use /generate-questions with streaming: true

Migration

  • Before: POST /generate-questions/stream-by-question
  • After: POST /generate-questions with "streaming": true in request body

New Parameter

  • streaming — Boolean parameter to enable SSE streaming mode (default: false)
  • When true, returns questions one at a time via Server-Sent Events
  • When false (default), returns all questions at once (batch mode)

Improvements

  • Single endpoint for both batch and streaming modes
  • Consistent API pattern matching the follow-up endpoint
  • Simplified client integration — same endpoint, just add a parameter