API:Data formats

Input
The API takes its input through parameters provided by the HTTP request in   or   format.

Every module and submodule has its own set of parameters, which are listed in the documentation and in action=help. They can also be retrieved through .

Encoding
All input should be valid UTF-8, in NFC form.

MediaWiki will attempt to convert other formats, which may result in an error.

Multivalue parameters
Parameters that take multiple values are normally submitted with the values separated using the pipe character( ), e.g.  .

If a value contains the pipe character in itself, use U+001F (Unit Separator) as the separator and prefix the value with U+001F, e.g. <tvar|3> </>.

Whether a parameter accepts multiple values is listed explicitly in its module documentation. t

Boolean parameters
If a boolean parameter is specified in an HTTP request, it is considered true regardless of its value. For a false value, omit the parameter entirely.

The best way to specify a true parameter in an HTTP request is to use ; the trailing   ensures the browser or HTTP library does not discard the "empty" someParam.

Timestamps
Parameters that take timestamp values accept multiple timestamp formats:


 * ISO 8601 format :.
 * MySQL's internal timestamp format :.
 * UNIX timestamp format  ( number of seconds since January 1, 1970 ).
 * UNIX timestamp format  ( number of seconds since January 1, 1970 ).

Timestamps are always output in ISO 8601 format.

Output
The standard and default output format in MediaWiki is JSON. All other formats are discouraged.

The output format should always be specified using  with yourformat being one of the following:

Response
Unless specified, all modules allow data output in all generic formats.

To simplify debugging, all generic formats have "pretty-print in HTML" alternatives with an  suffix, e.g. <tvar|1> </>.

JSON parameters
The following parameters can be used with <tvar|1> </> and <tvar|2> </>:


 * {{ApiParam|callback|The function in which the result will be wrapped. For safety, all user-specific data will be restricted.
 * {{ApiParam|callback|The function in which the result will be wrapped. For safety, all user-specific data will be restricted.
 * {{ApiParam|callback|The function in which the result will be wrapped. For safety, all user-specific data will be restricted.
 * {{ApiParam|callback|The function in which the result will be wrapped. For safety, all user-specific data will be restricted.
 * {{ApiParam|callback|The function in which the result will be wrapped. For safety, all user-specific data will be restricted.
 * {{ApiParam|callback|The function in which the result will be wrapped. For safety, all user-specific data will be restricted.

A number of things are disabled for security:


 * Tokens cannot be obtained so state-changing actions aren't possible.


 * The client is treated as an anonymous user (i.e. not logged in) for all purposes, even after logging in through <tvar|1>{{ll|API:Login|action{{=}}login}}</>. This means that modules which require additional rights won't work unless anonymous users are allowed to use them.

Additional notes

 * XML and PHP output formats are depracated but still in use. Clients written in PHP should avoid using the PHP format because it is fundamentally insecure.  It is maintained for now only due to its popularity.


 * There are many conversion libraries and online converters to convert JSON responses to other formats—for example, JSON-CSV converts to Comma-Separated Values.


 * Feed modules like api>Special:MyLanguage/API:Feedrecentchanges</>|Feed Recent Changes override the standard output format, instead using RSS or Atom, as specified by their  parameter.  In those cases, the format specified in the   parameter is only used if there's an error.