Donate using PayPal

CycleStreets API (v2)

  • Details for:
  • API overview
  • Obtain API key
  • Usage policy
  • Uptime policy

Add feedback

This API call is used to submit an item of feedback (e.g. on a route).

Clients are strongly encouraged to implement this call, so that we get feedback from users on problematic routes or other issues.


Example which adds an item of routing feedback.


	[type] => routing
	[itinerary] => 40669517
	[comments] => The second section of the route is failing to use the nearby cycle path which avoids a dropped kerb.
	[email] =>
	[name] => Susan Smith


    "id": "7462"

Request parameters - required

type string
The type of feedback. It is strongly recommended to implement at least the value 'routing' below. The list of all available values are:
  • abuse: Report abuse, e.g. inappropriate caption in a Photomap location caption
  • bug: General bug in functionality (not a routing problem), e.g. a GUI bug
  • journeyplanner: General feedback relating to the journey planner (not relating to a specific route)
  • mobile: Feedback relating to a mobile client's GUI (not a routing problem), e.g. button not working
  • other: Something else not in any of the other categories
  • photomap: Something relating to the photomap
  • routing: Feedback relates to a poor-quality route (e.g. user can give advice on a better route, or route is too busy, or reports a missing cut through, etc.). If using this option, you must include the optional itinerary field (or the API will respond with an error).
comments string
Comments from the user. Clients should encourage users to put useful text here rather than just 'bad route', as the latter is almost useless for helping us diagnose the problem. (Clients should not simply dump a 'Good/Bad' type boolean response here.) More advanced use here might see clients send data which indicates exactly which route segments were poor, and for what reason. (Please discuss the latter with us if you have ideas on this, as we may be able to amend this API call to accept such data in a more structured fashion.)

Request parameters - optional

Note that, if using these optional parameters, you can only send one of itinerary, url or waypoints.

itinerary int
Route itinerary ID, received from the journey.plan API call. You must include this if sending type=routing.
url string
A public route URL from the domain name (A small number of other domains are supported for the benefit of particular clients and known to those keyholders.)
waypoints string
A waypoint string, matching the format defined in the journey.plan API call.
email string
The user's e-mail address, which must be syntactically valid. This optional field enables us to respond to the user, perhaps to reply that route problems have been fixed or seeking more information.
name string
Name of the user. Purely a vanity field that enables us to respond more politely than 'Dear user,'.
reference string
A reference number provided by the client for its internal purposes when later retrieving a CycleStreets-provided response to feedback (API call not yet available).


JSON object as above, showing the ID of the saved feedback.

At present, this ID does not relate to any public URL but may become used in the future.

Error response

JSON object containing an error key and a text string.

Example error (text string will vary):

    "error": "Apologies - the CycleStreets website responded with an error when attempting to add this feedback."
    "error": "An itinerary number must be sent when submitting feedback on a route."
    "error": "More than one itinerary-related parameter (itinerary/url/waypoints) was sent."

We welcome your feedback, especially to report bugs or give us route feedback.

My comments relate to: *

Your comments: *
URL of page: *
How did you find out about CycleStreets?:
Your name:
Our ref: Please leave blank - anti-spam measure

* Items marked with an asterisk [*] are required fields and must be fully completed.