You can use "login" in Bugzilla::WebService::User to log in as a Bugzilla user. This issues standard HTTP cookies that you must then use in future calls, so your client must be capable of receiving and transmitting cookies.

You can specify Bugzilla_login and Bugzilla_password as arguments to any WebService method, and you will be logged in as that user if your credentials are correct. Here are the arguments you can specify to any WebService method to perform a login:

Methods are marked STABLE if you can expect their parameters and return values not to change between versions of Bugzilla. You are best off always using methods marked STABLE. We may add parameters and additional items to the return values, but your old code will always continue to work with any new changes we make. If we ever break a STABLE interface, we'll post a big notice in the Release Notes, and it will only happen during a major new release.

Methods (or parts of methods) are marked EXPERIMENTAL if we believe they will be stable, but there's a slight chance that small parts will change in the future.

Certain parts of a method's description may be marked as UNSTABLE, in which case those parts are not guaranteed to stay the same between Bugzilla versions.

If a particular webservice call fails, it will throw an error in the appropriate format for the frontend that you are using. For all frontends, there is at least a numeric error code and descriptive text for the error.

The various errors that functions can throw are specified by the documentation of those functions.

Each error that Bugzilla can throw has a specific numeric code that will not change between versions of Bugzilla. If your code needs to know what error Bugzilla threw, use the numeric code. Don't try to parse the description, because that may change from version to version of Bugzilla.

Note that if you display the error to the user in an HTML program, make sure that you properly escape the error, as it will not be HTML-escaped.

Many Webservice methods take similar arguments. Instead of re-writing the documentation for each method, we document the parameters here, once, and then refer back to this documentation from the individual methods where these parameters are used.

Many WebService methods return an array of structs with various fields in the structs. (For example, "get" in Bugzilla::WebService::Bug returns a list of bugs that have fields like id, summary, creation_time, etc.)

These parameters allow you to limit what fields are present in the structs, to possibly improve performance or save some bandwidth.