FixMyStreet support for Open311

FixMyStreet supports Open311 both as a client (sending reports made on the site to an external service via the Open311 protocol), and partly as a server (returning reports made on the site when queried via the Open311 protocol).

What is Open311?

In a nutshell, it's an international open standard that allows services to 'talk to' council systems.

As channels of communication diversify, it has become more and more important that council systems can recognise and accept reports from a variety of sources. For example, reports may come in via Twitter, SMS, email, services like FixMyStreet, and the council's own website.

Where can I find out more?

Open311 isn't as widely known as it deserves to be, so we wrote a short series of blog posts to explain the basics. And you can find out lots more at

Why does it matter?

If you oversee problem reports at a council, you will of course be concerned about future-proofing your communication channels in an easy and economical way – Open311 gives you that assurance.

You may be interested to know about FixMyStreet Pro, our hosted service which sits seamlessly on your council website.

We can integrate it with any council back-end system, but if you use Open311, we charge less. That's how much we believe it's the sane way forward for council problem-reporting systems.

Any questions?

We're always happy to talk. Just drop us a line.

Open311 API for the mySociety FixMyStreet server

At the moment only searching for and looking at reports work.

This API implementation is work in progress and not yet stabilized. It will change without warnings in the future.

At most 1000 requests are returned in each query. The returned requests are ordered by requested_datetime, so to get all requests, do several searches with rolling start_date and end_date.

The following Open311 v2 attributes are returned for each request: service_request_id, description, lat, long, media_url, status, requested_datetime, updated_datetime, service_code and service_name.

In addition, the following attributes that are not part of the Open311 v2 specification are returned: agency_sent_datetime, title (also returned as part of description), interface_used, comment_count, requestor_name (only present if requestor allowed the name to be shown on this site).

The Open311 v2 attribute agency_responsible is used to list the administrations that received the problem report, which is not quite the way the attribute is defined in the Open311 v2 specification.

With request searches, it is also possible to search for agency_responsible to limit the requests to those sent to a single administration. The search term is the administration ID provided by MaPit.


  • discovery information: XML or JSON
  • list of services provided: XML or JSON
  • list of services provided for WGS84 coordinate latitude 60 longitude 11: XML or JSON
  • Request number 1: XML or JSON
  • All requests with the category 'Other': XML or JSON
  • All closed requests: XML or JSON
  • All open requests reported before 2011-03-10 to Trondheim (id 1601): XML or JSON
  • All open requests in Asker (id 220) and Bærum (id 219): XML or JSON


The following search parameters can be used:

Search for numeric ID of specific request. Using this is identical to asking for a individual request using the /requests/number.format URL.
Search for the given category / service type string.
Search for open or closed (fixed) requests.
Only return requests with requested_datetime set after or at the date and time specified. The format is YYYY-MM-DDTHH:MM:SS+TZ:TZ.
Only return requests with requested_datetime set before the date and time specified. Same format as start_date.
ID of government body receiving the request. Several IDs can be specified with | as a separator.
Name / identifier of interface used.
Search for entries with or without photos. Use value 'true' to only get requests created with images, and 'false' to get those created without images.
Max number of requests to return from the search. If it is larger than the site specific max_requests value specified in the discovery call, the value provided is ignored.

The search result might look like this:

        <recipient>Statens vegvesen region øst</recipient>
      <description>Mangler brustein: Det støver veldig på tørre dager.  Her burde det vært brustein.</description>
      <detail>Det støver veldig på tørre dager.  Her burde det vært brustein.</detail>
      <interface_used>Web interface</interface_used>
      <requestor_name>Petter Reinholdtsen</requestor_name>
      <title>Mangler brustein</title>