Before we begin, it's important to understand what happens when you make an
API request. Basically:
Your request leaves your computer and crosses the internet to our servers.
Our software answers the request.
Our servers send the answer back to you, across the internet.
As you can imagine, the length of time for steps 1 and 3 will depend
on where you are on the internet.
Batch or Bulk geocoding
One idea that often comes up is to send multiple locations per request,
or to send a file full of locations that can be processed and then be
downloaded after all locations are geocoded. This is often referred to as
"batch" or "bulk" geocoding.
We intentionally don’t support more than one location per request as our
(hard earned) experience is that the conceptually much simpler
"one location, one request"
model is much less likely to lead to misunderstandings or errors of
implementation, thus saving engineering time, which is the most valuable
resource for almost all of our customers.
First of all, the fastest request is the one you don't make.
Unlike with many geocoding services that are built on non-open data, you can
store our results as long as you like, and whether you are a customer or not.
Can you do more
to reduce the number of requests you need to send us?
Do not use a proxy or VPN
If possible ensure your requests are coming directly to our servers, rather
than redirecting via a proxy.
Requesting in parallel rather than in series
Assuming that you looked in your cache, and decided that you do need to make
an API request, the way to
churn through your dataset quickly is to send many requests in parallel
(at the same time) rather than in series (one after another).
This option is not available to free trial users who are limtied to one
request per second. Paying customers can send us many more requests
per second (you can see the exact numbers on
our pricing page).
How you run requests in parallel will depend on the programming language
you are using, but essentially it is as simple as having multiple services
running at the same time.
We have customers geocoding millions of locations per day, requesting in
Speeding up individual requests
Nevertheless, there are several things you can do to help us answer your
request more quickly (Step 2 in the list above).
Do you need the information in our
If not adding the optional parameter
will skip that step and let us respond slightly more quickly.
It also reduces the size of the response considerably (and thus reduces
the amount of information we need to send back to you).
We cache forward geocoding requests, unless you have specified
So it may be slightly faster if you don't use that optional
parameter, though it will depend on how common your requests
Finally, turning pretty printing off, ie NOT using
marginally reduces the response size.
All that being said, generating the response is typically very
fast, almost always the bulk of the time is spent in crossing the
internet (Steps 1 and 3 above).
Our servers are at redundant locations in Germany and are
well connected to the major networks. Nevertheless, there is no
escaping the fact that a request from the US west coast - for
example - has to cross the Atlantic twice.
Our server performance in independently monitored by StatusCake.
see how we are doing here.