Open311 Reporting API

This document includes suggested changes to the Open311 GeoReport v2 API to make it a more generic report it API for government.

Changes are highlighted in red. Within the API Methods section new attributes or elements are highlighted with a red background. Updates to existing elements are highlighted with a yellow background.

API

Collaboration for an Open311 Standard

The GeoReport API v2 allows developers to build applications to both view and report issues which government entities like cities are responsible for addressing. These interactions are often referred to as "service requests" or "calls for service" and have traditionally been handled by custom web forms or phone based call centers (sometimes using the 311 phone number or other short-code). The GeoReport API is designed to allow both government and third party developers to create new applications and technologies that can integrate directly with these same official contact centers in any government that supports the standard. The current specification is focused on location-based non-emergency issues such as graffiti, potholes, and street cleaning.

The API consists of two main kinds of resources: services and service requests, but some servers that can't generate a realtime service request may also rely on a token resource. In total there are six methods used to interact with these resources: GET services, GET a service definition (a specific service_code id), POST a request, GET requests, GET a request (a specific service_request_id). The documentation below (starting from the API Methods section) is ordered based on a common sequence of interactions where a person first sees a list of available service types, selects one and creates a new service request, and then is able to track the status of that request and other requests. However each method can be accessed independently and some applications may only be focused on querying existing service requests to do analytics.

Service Discovery

GeoReport v2 and subsequent Open311 APIs are also required to have a standard service discovery file associated with them to provide routing between versions and types of APIs. See the Service Discovery page for details of the specification.

Internationalization and Encoding

Date/time format

All date/time fields must be formatted in a common subset of ISO 8601 as per the w3 note. Timezone information (either Z meaning UTC, or an HH:MM offset from UTC) must be included.

Examples:

Encoding

UTF-8 is required everywhere.

All text returned by the service, whether in XML, JSON, or any other text-based content-type, MUST be encoded as UTF-8. Appropriate HTTP headers must be set, and the root element must be preceded with the XML declaration including the encoding="UTF-8" attribute. All text received by the service from the client will be assumed to be UTF-8 and must be decoded accordingly. Examples of the HTTP content-type headers for each format are shown below under Format Support.

Format Support

XML is a required format, but JSON can be provided at the discretion of the API provider. The output formats supported by the provider are indicated through the Service Discovery formats field for the API endpoint being used. The client can specify the desired format by appending the format name to the resource. For example a GET request to /services.xml for text/xml output from the services resource and /services/01.json for application/json (RFC 4627) output for a specific service definition.

The HTTP content-type headers should look like this for each format:

POST Service Request: Content-Type: application/x-www-form-urlencoded; charset=utf-8

XML: Content-Type: text/xml; charset=utf-8

JSON: Content-Type: application/json; charset=utf-8

XML Support

XML for the API should be Content-Type: text/xml. The XML output currently defined is schemaless and without a namespace declaration. For now, extending the output with additional namespaces should be done at your own risk. To guarantee that all clients can support the XML output, it is recommended that you adhere to the specification strictly and do not include foreign tags or namespaces. It is also assumed that the default namespace is not specified, but if it must be specified, the XMLNS URI is the URL of the specification: http://wiki.open311.org/GeoReport_v2

JSON Support

JSON for the API should be Content-Type: application/json. JSON support is based on a programmatic mapping of the XML format using the Spark Convention. This means that if you have an XML file, you can easily generate the JSON version with XSL. This can be done using a server side XSLT (php example).

The service should also support content negotiation using the Accept HTTP header for extenionless URLs.

Definitions

jurisdiction_id

As a means to allow this API to distinguish multiple jurisdictions within one API endpoint we've included a "jurisdiction_id" which will be the unique identifier for cities. It has been suggested that we use the jurisdiction's main website root url (without the www) as the "jurisdiction_id". For San Francisco, the jurisdiction_id is sfgov.org. Implementations can ignore this parameter and treat it as an "Optional Argument" if the implementation only serves one jurisdiction.

Optional Arguments

"Optional" means that the response should be the same whether a parameter is passed and is empty or is not passed at all. A null parameter should be treated as equivalent to a non-declared parameter in processing the request.

API methods

GET Service List

Purpose provide a list of acceptable 311 service request types and their associated service codes. These request types can be unique to the city/jurisdiction.
URL https://[API endpoint]/services.[format]
Sample URL https://api.city.gov/dev/v2/services.xml?jurisdiction_id=city.gov
Formats XML (JSON available if denoted by Service Discovery)
HTTP Method GET
Requires API Key No


Required Arguments

Field Name Description Notes & Requirements
jurisdiction_id
This is only required if the endpoint serves multiple jurisdictions

Response

Field Name Description Notes & Requirements
services ⇊
service ↴
service_code
The unique identifier for the service request type
service_name
The human readable name of the service request type
description
A brief description of the service request type.
metadata
Determines whether there are additional form fields for this service type.
  • true: This service request type requires additional metadata so the client will need to make a call to the Service Definition method.
  • false: No additional information is required and a call to the Service Definition method is not needed.
Possible values: true, false.
type
  • realtime: The service request ID will be returned immediately after the service request is submitted.
  • batch: A token will be returned immediately after the service request is submitted. This token can then be later used to return the service request ID.
  • blackbox: No service request ID will be returned after the service request is submitted
Possible values: realtime, batch, blackbox.
keywords
A comma separated list of tags or keywords to help users identify the request type. This can provide synonyms of the service_name and group.
group
A category to group this service type within. This provides a way to group several service request types under one category such as "sanitation"
customer_required
A category to group this service type within. This provides a way to group several service request types under one category such as "sanitation" Possible values: required, optional, not_required.
location_required
A category to group this service type within. This provides a way to group several service request types under one category such as "sanitation" Possible values: required, not_required.
location_type
The type of location that should be provided:
  • any: Any of the following types.
  • residential: A residential property UPRN as defined in the LLPG or text in the address_string.
  • commercial: A commercial property UPRN as defined in the LLPG or text in the address_string.
  • street: A USRN or text in the address_string.
  • point: A point e.g. long/lat
Possible values: any, residential, commercial, street, point.

Possible Errors

The numbers represent the HTTP status code returned for each error type:

GET Service Definition

Conditional Yes - This call is only necessary if the Service selected has metadata set as true from the GET Services response
Purpose Define attributes associated with a service code. These attributes can be unique to the city/jurisdiction.
URL https://[API endpoint]/services/[service_code].[format]
Sample URL https://api.city.gov/dev/v2/services/033.xml?jurisdiction_id=city.gov
Formats XML (JSON available if denoted by Service Discovery)
HTTP Method GET
Requires API Key No


Required Arguments

Field Name Description Notes & Requirements
jurisdiction_id
This is only required if the endpoint serves multiple jurisdictions
service_code
The service_code is specified in the main URL path rather than an added query string parameter.


Response

Field Name Description Notes & Requirements
service_definition ↴
service_code
Returns the service_code associated with the definition, the same one submitted for this call.
attributes ⇊
attribute ↴
variable
  • true denotes that user input is needed
  • false means the attribute is only used to present information to the user within the description field
Possible values: true, false.
code
A unique identifier for the attribute
datatype
Denotes the type of field used for user input.
  • string: A string of characters without line breaks. Represented in an HTML form using an <input> tag
  • number: A numeric value. Represented in an HTML form using an <input> tag
  • datetime: The input generated must be able to transform into a valid ISO 8601 date. Represented in an HTML form using <input> tags
  • text: A string of characters that may contain line breaks. Represented in an HTML form using an <textarea> tag
  • singlevaluelist: A set of predefined values (specified in this response) where only one value may be selected. Represented in an HTML form using the <select> and <option> tags
  • multivaluelist: A set of predefined values (specified in this response) where several values may be selected. Represented in an HTML form using the <select multiple="multiple"> and <option> tags

The list of values to be expanded to include HTML5 input types e.g. hidden, tel, url, email, password, datetime, date, month, week, time, datetime-local, range, color.

 Options: string, number, datetime, text, singlevaluelist, multivaluelist.
required
  • true means that the value is required to submit service request
  • false means that the value not required.
Options: true, false.
datatype_description
A description of the datatype which helps the user provide their input
order
The sort order that the attributes will be presented to the user. 1 is shown first in the list. Any positive integer not used for other attributes in the same service_code
description
An description of the attribute field with instructions for the user to find and identify the requested information
The following attributes from the HTML5 specification should be available to support validation of the data including: max, maxlength, min, pattern, placeholder, step.
Not sure how best to achieve this. Either add each of these as optional elements or have a validation element with child elements.
values ⇊
value ↴
key
The unique identifier associated with an option for singlevaluelist or multivaluelist. This is analogous to the value attribute in an html option tag.
name
The human readable title of an option for singlevaluelist or multivaluelist. This is analogous to the innerhtml text node of an html option tag.
group
This is analogous to the optgroup tag.


Possible Errors

The numbers represent the HTTP status code returned for each error type:

POST Service Request

Purpose Create service requests
URL https://[API endpoint]/requests.[format]
Sample URL https://api.city.gov/dev/v2/requests.xml
Format sent Content-Type: application/x-www-form-urlencoded
Formats returned XML (JSON available if denoted by Service Discovery)
HTTP Method POST
Requires API Key Yes


Required Arguments

Field Name Description Notes & Requirements
jurisdiction_id
This is only required if the endpoint serves multiple jurisdictions
service_code
This is obtained from GET Service List method
location parameter
A full location parameter must be submitted. One of lat & long or address_string or address_id
attribute
An array of key/value responses based on Service Definitions. This takes the form of attribute[code]=value where multiple code/value pairs can be specified as well as multiple values for the same code in the case of a multivaluelist datatype (attribute[code1][]=value1&attribute[code1][]=value2&attribute[code1][]=value3) - see example.
This is only required if the service_code requires a service definition with required fields.


Optional Arguments

Field Name Description Notes & Requirements
lat
Latitude using the (WGS84) projection. lat & long both need to be sent even though they are sent as two separate parameters. lat & long are required if no address_string or address_id is provided.
long
Longitude using the (WGS84) projection. lat & long both need to be sent even though they are sent as two separate parameters. lat & long are required if no address_string or address_id is provided.
address_string
Human entered address or description of location. This is required if no lat/long or address_id are provided. This should be written from most specific to most general geographic unit, eg address number or cross streets, street name, neighborhood/district, city/town/village, county, postal code.
address_id
The internal address ID used by a jurisdiction's master address repository or other addressing system. This is required if no lat/long or address_string are provided.
email
The email address of the person submitting the request
device_id
The unique device ID of the device submitting the request. This is usually only used for mobile devices. Android devices can use TelephonyManager.getDeviceId() and iPhones can use [UIDevice currentDevice].uniqueIdentifier
account_id
The unique ID for the user account of the person submitting the request
first_name
The given name of the person submitting the request
last_name
The family name of the person submitting the request
phone
The phone number of the person submitting the request
description
A full description of the request or report being submitted. This may contain line breaks, but not html or code. Otherwise, this is free form text limited to 4,000 characters.
media_url
A URL to media associated with the request, eg an image. A convention for parsing media from this URL has yet to be established, so currently it will be done on a case by case basis much like Twitter.com does. For example, if a jurisdiction accepts photos submitted via Twitpic.com, then clients can parse the page at the Twitpic URL for the image given the conventions of Twitpic.com. This could also be a URL to a media RSS feed where the clients can parse for media in a more structured way.


Response

Field Name Description Notes & Requirements
service_requests ⇊
request ↴
service_request_id
The unique ID of the service request created. This should not be returned if token is returned
token
If returned, use this to call GET service_request_id from a token. This should not be returned if service_request_id is returned
service_notice
Information about the action expected to fulfill the request or otherwise address the information reported. May not be returned
account_id
The unique ID for the user account of the person submitting the request. May not be returned


Possible Errors

The numbers represent the HTTP status code returned for each error type:

GET service_request_id from a token

Conditional Yes - This call is only necessary if the response from POST Service Request contains a token
Purpose Get the service_request_id from a temporary token. This is unnecessary if the response from creating a service request does not contain a token.
URL https://[API endpoint]/tokens/[token id].[format]
Sample URL https://api.city.gov/dev/v2/tokens/123456.xml?jurisdiction_id=city.gov
Formats XML (JSON available if denoted by Service Discovery)
HTTP Method GET
Requires API Key No


Required Arguments

Field Name Description Notes & Requirements
jurisdiction_id
This is only required if the endpoint serves multiple jurisdictions
token
This is obtained from the POST Service Requests method


Response

Field Name Description Notes & Requirements
service_requests ⇊
request ↴
service_request_id
The unique ID for the service request created. This can be used to call the GET Service Request method.
token
The token ID used to make this call.


Possible Errors

The numbers represent the HTTP status code returned for each error type:

GET Service Requests

Purpose Query the current status of multiple requests
URL https://[API endpoint]/requests.[format]
Sample URL https://api.city.gov/dev/v2/requests.xml?start_date=2010-05-24T00:00:00Z&end_date=2010-06-24T00:00:00Z&status=open&jurisdiction_id=city.gov
Formats XML (JSON available if denoted by Service Discovery)
HTTP Method GET
Requires API Key No


Required Arguments

Field Name Description Notes & Requirements
jurisdiction_id
This is only required if the endpoint serves multiple jurisdictions

Optional Arguments

Field Name Description Notes & Requirements
service_request_id
To call multiple Service Requests at once, multiple service_request_id can be declared; comma delimited. This overrides all other arguments.
service_code
Specify the service type by calling the unique ID of the service_code. This defaults to all service codes when not declared; can be declared multiple times, comma delimited
start_date
Earliest datetime to include in search. When provided with end_date, allows one to search for requests which have a requested_datetime that matches a given range, but may not span more than 90 days. When not specified, the range defaults to most recent 90 days. Must use w3 format, eg 2010-01-01T00:00:00Z.
end_date
Latest datetime to include in search. When provided with start_date, allows one to search for requests which have a requested_datetime that matches a given range, but may not span more than 90 days. When not specified, the range defaults to most recent 90 days. Must use w3 format, eg 2010-01-01T00:00:00Z.
status
Allows one to search for requests which have a specific status. This defaults to all statuses; can be declared multiple times, comma delimited; Options: open, closed

Response

Field Name Description Notes & Requirements
service_requests ⇊
request ↴
service_request_id
The unique ID of the service request created.
status
The current status of the service request.
  • open: it has been reported.
  • closed: it has been resolved.
Options: open, closed
status_notes
Explanation of why status was changed to current state or more details on current status than conveyed with status alone. May not be returned
service_name
The human readable name of the service request type
service_code
The unique identifier for the service request type
description
A full description of the request or report submitted. This may contain line breaks, but not html or code. Otherwise, this is free form text limited to 4,000 characters.
agency_responsible
The agency responsible for fulfilling or otherwise addressing the service request. May not be returned
service_notice
Information about the action expected to fulfill the request or otherwise address the information reported. May not be returned
requested_datetime
The date and time when the service request was made. Returned in w3 format, eg 2010-01-01T00:00:00Z
updated_datetime
The date and time when the service request was last modified. For requests with status=closed, this will be the date the request was closed. Returned in w3 format, eg 2010-01-01T00:00:00Z
expected_datetime
The date and time when the service request can be expected to be fulfilled. This may be based on a service-specific service level agreement. May not be returned
address
Human readable address or description of location. This should be provided from most specific to most general geographic unit, eg address number or cross streets, street name, neighborhood/district, city/town/village, county, postal code.
address_id
The internal address ID used by a jurisdictions master address repository or other addressing system.
zipcode
The postal code for the location of the service request.
lat
latitude using the (WGS84) projection.
long
longitude using the (WGS84) projection.
media_url
A URL to media associated with the request, eg an image. A convention for parsing media from this URL has yet to be established, so currently it will be done on a case by case basis much like Twitter.com does. For example, if a jurisdiction accepts photos submitted via Twitpic.com, then clients can parse the page at the Twitpic URL for the image given the conventions of Twitpic.com. This could also be a URL to a media RSS feed where the clients can parse for media in a more structured way.


Response Volume

Possible Errors

The numbers represent the HTTP status code returned for each error type:


GET Service Request

Purpose Query the current status of an individual request
URL https://[API endpoint]/requests/[service_request_id].[format]
Sample URL https://api.city.gov/dev/v2/requests/123456.xml?jurisdiction_id=city.gov
Formats XML (JSON available if denoted by Service Discovery)
HTTP Method GET
Requires API Key No


Required Arguments

Field Name Description Notes & Requirements
jurisdiction_id
This is only required if the endpoint serves multiple jurisdictions
service_request_id
The service_request_id is specified in the main URL path rather than an added query string parameter.


Optional Arguments

None

Response

Field Name Description Notes & Requirements
service_requests ⇊
request ↴
service_request_id
The unique ID of the service request created.
status
The current status of the service request.
  • open: it has been reported.
  • closed: it has been resolved.
Options: open, closed
status_notes
Explanation of why status was changed to current state or more details on current status than conveyed with status alone. May not be returned
service_name
The human readable name of the service request type
service_code
The unique identifier for the service request type
description
A full description of the request or report submitted. This may contain line breaks, but not html or code. Otherwise, this is free form text limited to 4,000 characters.
agency_responsible
The agency responsible for fulfilling or otherwise addressing the service request. May not be returned
service_notice
Information about the action expected to fulfill the request or otherwise address the information reported. May not be returned
requested_datetime
The date and time when the service request was made. Returned in w3 format, eg 2010-01-01T00:00:00Z
updated_datetime
The date and time when the service request was last modified. For requests with status=closed, this will be the date the request was closed. Returned in w3 format, eg 2010-01-01T00:00:00Z
expected_datetime
The date and time when the service request can be expected to be fulfilled. This may be based on a service-specific service level agreement. May not be returned
address
Human readable address or description of location. This should be provided from most specific to most general geographic unit, eg address number or cross streets, street name, neighborhood/district, city/town/village, county, postal code.
address_id
The internal address ID used by a jurisdictions master address repository or other addressing system.
zipcode
The postal code for the location of the service request.
lat
latitude using the (WGS84) projection.
long
longitude using the (WGS84) projection.
media_url
A URL to media associated with the request, eg an image. A convention for parsing media from this URL has yet to be established, so currently it will be done on a case by case basis much like Twitter.com does. For example, if a jurisdiction accepts photos submitted via Twitpic.com, then clients can parse the page at the Twitpic URL for the image given the conventions of Twitpic.com. This could also be a URL to a media RSS feed where the clients can parse for media in a more structured way.


Possible Errors

The numbers represent the HTTP status code returned for each error type:

Errors

Response

Field Name Description Notes & Requirements
errors ⇊
error ↴
code
The error code representing the type of error. In most cases, this should match the HTTP status code returned in the HTTP header.
description
A human readable description of the error that occurred. This is meant to be seen by the user.

HTTP error codes are required, but the code in the response body shouldn't necessarily match the HTTP error code, so that more specific and unique error code identifiers can be used. The HTTP error codes should always be 404 for resources that don't exist, 403 for errors because of wrong or missing api_key and basically 400 for any other error where the request can not be fulfilled as expected. Multiple errors codes and descriptions can be returned in the body (the response is an array).