REST reference
Base URL:https://verelyn.com/api/external/v1. Send the bearer token obtained by browser OAuth. Never paste it into documentation, a support message, or a chat. These routes are deployed contracts; authorized live use is access dependent.
Exact write bodies
UUID fields arecommand_id, draft_id, target_answer_id, item_id, alert_id, and a monitor path {id}. question_id is a non-empty string of at most 160 characters; use the value returned by the service unchanged.
POST /mandate:
expected_revision is a non-negative integer; statement is 1–2,000 characters; provenance is reader_words or assistant_suggestion. GET /mandate does not expose the revision, so use the web editor unless a supported product flow supplied it.
POST /monitors takes exactly one field, never both:
POST /monitors/{id}:
state is active, paused, or stopped. GET /updates supplies alert IDs as items[].id; GET /briefing does not expose edition item IDs, so use the web edition for that starting path.
POST /onboarding:
POST /onboarding/answers always requires UUID draft_id, UUID command_id, non-negative expected_revision, action, and provenance (reader_answer or assistant_suggestion). action is answer, correct, skip, or retry. answer requires question_id, question_text, and non-empty answer; correct also requires UUID target_answer_id; skip requires the two question fields; retry needs no extra action field. Optional timezone is an IANA time-zone name.
An accepted answer can return:
Response envelopes
REST success returns the documented object directly as JSON. A successful mandate correction is shaped like:{"error":{"code":"invalid_cursor","message":"That cursor is not one this newsroom issued."}}. An internal_error may also contain correlation_id, which is safe to quote to support. Authorization failures are generic and do not disclose whether another account owns an identifier.