The static information on this website for each planning application, planning area and postcode is available via REST style URLs, as follows:
/planapplic/
/planarea/
/postcode/

You can also search for planning applications using this endpoint:
/api/applics/

And you can get lists of planning areas and their relations using this end point:
/api/areas/

The data records returned by the API are described in the Data Dictionary

Note: this is a draft API specification and may be subject to change

Note: access to the API is now rate limited. Enquire for futher details.

REST URLs

Planning Application
/planapplic/{applic_name}/{fmt}
/planapplic/{anyid}@{planarea}/{fmt}
Planning Area
/planarea/{planarea}/{fmt}
Postcode
/postcode/{postcode}/{fmt}
  • {fmt} the data format - either 'xml', 'geojson' or 'json' (add a 'callback' key for JSONP), otherwise, if empty, an html page is returned
  • {applic_name} a unique name for the planning application in this system
  • {planarea} the unique name or numeric id of a planning area in this system
  • {anyid} a unique identifier for the planning application within its authority
  • {postcode} a full (eg SW1Y 1AY) or partial (e.g. SW1) UK postcode

Searching for Planning Applications

/api/applics/{fmt}?{query}

  • {fmt} data format - either 'xml', 'geojson', 'georss' or 'json' (add a 'callback' key for JSONP)
  • {query} encoded key=value pairs, with keys as follows:
  • limit -> the maximum total results to return for this query (default 500)
  • pg_sz -> page size - the maximum results from the query to return in one batch (default 50)
  • index OR page -> the result page returned will start at this index number (commencing from zero) or at this page number (starting at page 1)
  • sort -> comma separated fields to sort results on (ascending, or if prefix is '-', descending)
  • recent -> only planning applications within this number of recent days are returned (0 means today)
  • start_date -> only planning applications after (and including) this date are returned (all dates in YYYY-MM-DD or DD/MM/YYYY format)
  • end_date -> only planning applications before (and including) this date are returned
  • lat -> latitude = the N/S coordinate for the centre of a location search (in the range +48 to +62)
  • lng -> longitude = the W/E coordinate for the centre of a location search (in the range -11 to +4)
  • pcode -> postcode = UK postcode to use for the centre of a location search
  • krad -> radius (km) = only planning applications within the circle perimeter are returned (default 5)
  • bbox -> only planning applications within this bounding box are returned = 4 comma separated lat/lon values in the order West (min lon), South (min lat), East (max lon), North (max lat)(and note lat/on range limits above)
  • boundary -> only planning applications within this Polygon are returned = coordinates formatted as '[[x1,y1],[x2,y2],[x3,y3],[x4,y4],...]'
  • auth -> name or numerical id of a planning area, if you only want results from one area and optionally its sub-areas (see 'no_kin')
  • no_kin -> include this key (set to any value), if you only want results from one area and not its sub-areas
  • not_near -> include this key (set to any value), if you want a circle search to be based on recency not proximity
  • id_match -> either the exact 'uid' field or text which is contained in the 'altid' field of matching applications

Note: if a location search is undertaken (latitude and longitude, or postcode are supplied), the nearest 'limit' applications to the centre point are returned by default in order of proximity (unless 'radius' and 'not_near' are set, in which case the most recent 'limit' applications are returned by default in most recent first order). If not a location search, the most recent 'limit' applications are returned (by default in most recent first order).
Note: if 'lat' and 'lng' are supplied then 'bbox' is ignored
Note: if 'recent' is supplied then 'start_date' and 'end_date' are ignored

Example: /api/applics/json?auth=Hackney&start_date=2010-10-01&end_date=2010-10-02&pg_sz=10&limit=20

Searching for Planning Areas

/api/areas/{fmt}?{query}

  • {fmt} data format - either 'xml' or 'json' (add a 'callback' key for JSONP)
  • {query} encoded key=value pairs, with keys as follows:
  • pg_sz -> page size - the maximum results to return in one batch (default 10)
  • index OR page -> the result page returned will start at this index number (commencing from zero) or at this page number (starting at page 1)
  • sort -> comma separated fields to sort results on (ascending, or if prefix is '-', descending)
  • One of the following:
    • auth AND relation -> auth is the name or numerical id of a planning authority and relation can be 'regions', 'parent', 'offspring', 'siblings', 'children', 'ancestors', 'allsibs'
    • auths -> text to match in the name to find multiple planning areas, or this can be a comma separated list of names or ids to list multiple authorities
    • region -> returns areas within a region (one of CI, EA, EM, IM, LO, NE, NW, NI, SC, SE, SW, WA, WM, YH), or if 'all' returns all choices, or if 'multi' returns cross regional areas or if 'super' returns areas above regional level , or if 'regions' returns list of regions
    • area_type -> finds areas matching a specific type (one of CA, CB, CD, EC, ED, ER, UA, LB, MB, MC, NP, ND, OP, SD, UN, WD), or if 'planning' returns all planning authorities, or if 'active' returns only planning areas with planning applications

Note: by default the results are returned in alphabetical name order (except for relations 'offspring' and 'ancestors')

Example: /api/areas/json?auth=Hackney&relation=siblings&pg_sz=10