POST request

Making edits, and, indeed, any POST request, is a multi-step process.

1. Log in, via one of the methods described in API:Login . Note that while this is required to correctly attribute the edit to its author, many wikis do allow users to edit without registering or logging into an account.

2. GET a {{ll|Manual:Edit token|CSRF token}}:

3. Send a POST request, with the CSRF token, to take action on a page:

The Response section below is for the final POST request, to take action on the page. See the pages on API:Login and API:Tokens for the intermediary JSON responses to earlier steps.

Also note that the tokens in the queries on this page are sample values. Actual tokens are unique to each login session and cross-site request. They are included only to demonstrate how to properly format queries.

Response

{
    "edit": {
        "result": "Success",
        "pageid": 94542,
        "title": "Wikipedia:Sandbox",
        "contentmodel": "wikitext",
        "oldrevid": 371705,
        "newrevid": 371707,
        "newtimestamp": "2018-12-18T16:59:42Z"
    }
}

Edit conflicts

The Python sample is a basic implementation of an edit request by a registered user. In real-world scenarios, care should be taken to prevent edit conflicts. These occur when two or more users are attempting to edit the same page at the same time.

Conflicts can be prevented by retrieving the last {{ll|API:Revisions|revision}} timestamp when we request a CSRF token. Adding prop=info|revisions to the CSRF token request in Step 3 allows us to access the timestamp for the last revision. This timestamp will be used as the basetimestamp when we make our the edit request.

We also need the exact time when we start our edit. This can be retrieved by adding curtimestamp to the CSRF request as well. This value will serve as our starttimestamp.

Finally, in the actual edit request, set the basetimestamp and starttimestamp parameters, like so:

Large edits

POST requests containing large amounts of text content (8000+ characters) should be sent with Content-Type: multipart/form-data indicated in the header. Because multipart/form-data does not need to add HTML escape characters (i.e., percent encoding) for spaces and punctuation, the amount of data passed will subsequently be much smaller than the percent-encoded equivalent.

However, there is still some overhead added by multipart/form-data -- roughly, 160 bytes per parameter. For short messages that don't require adding many escape characters, this amount of overhead can be inefficient, and percent-encoding is preferred.^[1]

Note that in our Python sample code, the request is percent-encoded by default.

See the MDN web docs for a more technical discussion of content-type and POST requests. See the Python Requests documentation for how to pass multipart/form-data using syntax similar to our Python sample code.

CAPTCHAs

If the wiki you are targeting uses {{ll|CAPTCHA|CAPTCHAs}}, your request may return an error containing an id number and a simple test, such as a question, a math problem, or an URL to an image. In order to complete your edit, you must complete the test, then retry your request with the id and the correct answer(s) appended to the original query string, like so: captchaid=sampleId&captchaword=answer

Other CAPTCHA systems and extensions may use different parameters for similar use. In general, use the field names for the id and test questions as the parameters in your second request.