riddle_publish

com.riddle/creator · Verify this server

Publishes one or many Riddles; meaning each Riddle will be available via https://www.riddle.com/view/[RIDDLEID]. Pass UUID for a single Riddle - the response is then the same compact build-configuration envelope riddle_get returns, with the new published state under "context.published"; use "omit" to shrink it the same way as riddle_get. Pass UUIDs (array of Riddle UUID strings, max 100) to publish several at once; the response is then the bulk envelope {bulk: true, operation, summary: {total, succeeded, failed}, results: [...]} with one entry per Riddle, each carrying its new state (title, viewUrl, published, modified) instead of a full build configuration - call riddle_get for the ones you want to inspect in detail. A bulk publish is not atomic and never gives up early: a Riddle that cannot be published is reported as that entry's "error" while all other Riddles are still published. A Riddle that fails publish validation says exactly why: the call fails with error "RIDDLE_PUBLISH_VALIDATE" (for a bulk, that entry's "error") carrying "validationErrors" - one {message, code, ...} entry per reason, e.g. code "MIN_ONE_BLOCK", "MIN_ONE_RESULT", "REDIRECT_RESULT_WITHOUT_URL" or "LOGIC_DEAD_ENDS" - so fix those and publish again. Non-blocking findings arrive as "validationWarnings" in the same shape, on a FAILED and on a SUCCESSFUL publish alike (the Riddle is live either way; e.g. "NO_DOMAINS" or "USES_OLD_LAYOUT") - report them to the user instead of retrying. Warnings are only stated when there are any. Publish validation only runs on a publish: riddle_builder_validate dry-runs a build configuration, not a publish, so there is no way to see these lists without calling this tool.