Before you start
If you haven't yet, create an account in the Developer Network so you can manage your keys, post in the forums, and feel like you are part of the mapping community. A free key is automatically created when signing up.
Share your Developer Network login credentials with your co-workers in case a change needs to be made while you're out of the office or after that promotion you've been after. It's a good idea to use a distribution list email for the Developer Network login. Announcements will go to the list rather than one person.
Monitoring
Each service can be tested by a monitor once per minute. These requests will be counted along with application requests toward your purchased transaction counts.
Load testing
Load testing must not be run unannounced. Please contact the support team with the specific time, volume, services to be tested, and preferably sample requests to be performed. These are shared apis - let's be respectful of everyone using them.
Overall
Single line addresses are parsed into separate address portions before being fed to the geocoder. To streamline the process, provide the geocoder the separated address elements (street address, city, state, etc.) from the start. This makes the process quicker and less error prone.
Remove any address line 2 text from the address. This includes any apartment number, unit, floor, office, PO Box, mile marker, trailer, hanger, pier, department, further instructions, phone numbers, attention, or "ring doorbell then go around the back but watch out for the dog".
Encoding - do it. Requests to the apis should have the parameter values url encoded. So if there is an ampersand in your address, encode it or the api will think it's a new parameter and return unexpected results and errors.
If you have more than one location to geocode, consider using a batch geocode.
Inexact or invalid input can produce more than one location for a given address. In this case the returned ambiguities can either be ignored and continue the process with the first/best result, the process can stop, or the ambiguous results can be checked or viewed before continuing the process.
The search/v2 api is optimized to search close to an origin. Smaller search areas will be much quicker and reliable than vast areas. Searches with a large buffer, 5 miles wide, along a long corridor, 100 miles long, will be slow and may be more likely to return unexpected results.
Smaller tables will also return faster and more reliable results. Searching tables with millions of rows can be far slower than smaller, more specific, data sets.
The Search api is also optimized for spatial, rather than string, searching. While there is the ability to add extra criteria to a spatial search, it should be used to filter spatial results rather than a filter for a large spatial area which turns the search into a general string search. Complex string criteria filtering is not the intent of the Search api. There are far better methods for string searching than a spatial database.
Routes are limited by both locations and distance.
A route is limited to 50 locations. An optimized route is limited to 25 locations. A route matrix is limited to 100 (one to many), 50 (many to one), or 25 (all to all) locations.
All routes are limited to 8000 total miles.
A static map can contain a route highlight. To avoid long urls, use a route sessionId rather than a long set of shape points. Each route will return a session which can be used in the static map api.
Map sdks
Too many objects on a map (markers, routes, overlays, images), any map, will make the map slow. A common practice is to limit objects on the map to the viewable map at appropriate zoom levels. A country wide view with thousands of objects on the map will most likely look like mud - very slow moving mud.
IP whitelisting
The ips for www.mapquestapi.com are 64.12.106.130, 205.188.201.198, 207.200.103.5 using the usual http (80) and https (443) ports.
Comments