Propose a new entry
propose_new_entryPropose a new entry for a reviewer to decide: it waits in Console → Applications under Quick proposals (list_applications with tab "proposals") and becomes live when approved. Refused (not_accepting) while Settings pauses new-entry requests, unless this account may create entries itself. For someone or something with no Wikidata item, leave out qid. With qid, the entry is linked to that item, and after approval Wikidata keeps up to date whatever you did not write (and any field in let_wikidata_manage). Refused, naming the entry, when one is already on the item. A merged-away QID is refused (409 qid_merged), naming the item Wikidata kept in wikidata_item: propose on that one. Sending the same proposal again within 15 minutes answers with the first one. note tells the reviewer why. Audited. Dry run by default: it names the entries already on the item, a short name already taken or held by a site redirect (short_is_redirect), and handles already on another entry. Related entries link themselves: when it is approved, this entry and the other new entries this account proposed within a day link each other both ways on the first plain-text mention of each title, so write names as plain text and file no follow-up to add links; the dry run lists them (related_entries, links_on_approval).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| qid | No | The Wikidata item, e.g. "Q42". Leave it out for an entry with no item. | |
| note | No | Why you propose this, in plain words: posted as the proposal’s first comment, which the reviewer reads with it. At most 2,000 characters. Never an internal tracking ID (a backlog or ticket number); a VHID is fine. | |
| short | No | The short name, as in verifiedhandles.org/<short>. Whether it is free is checked when the proposal is approved. | |
| title | Yes | ||
| dry_run | No | true (the default): write nothing — show the change and the exact request it would send. false: make the change. | |
| handles | No | ||
| subtitle | No | ||
| description | No | HTML; it is sanitised when stored. | |
| idempotency_key | No | Optional: a key you choose (1–255 printable ASCII, e.g. a UUID), sent as the write’s Idempotency-Key. Calling again with the same key and the same change within 24 hours answers the first call’s result (replayed: true) and writes nothing; the same key with another change is refused (422). | |
| let_wikidata_manage | No | With qid: fields you give that Wikidata should keep up to date after approval, as the console form does for a title it prefilled and you left as it was. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | A dry run: what to do next to make the change, in words. | |
| result | No | A real run: the route’s own answer, where the tool adds facts of its own beside it. | |
| confirm | No | A dry run of a change that needs it: the exact target to send back as `confirm` with dry_run: false. | |
| dry_run | No | true: a dry run, which wrote nothing. Absent from a real run. | |
| replayed | No | A real run with an idempotency_key already used for this change: the first call’s answer, given back; nothing was written now. | |
| would_send | No | A dry run: the exact request the real run would send (`method`, `path`, any `headers` such as an Idempotency-Key, and its `body`, `form` or `query`), or the requests, in order. | |
| may_edit_live | No | A dry run of a live edit: whether this key’s account may edit this entry live. | |
| refused_because | No | A dry run the real run would be refused for: why, in words. |