Data Axle Frequently Asked Questions
Chrome is the recommended browser for data-axle.com. However, the following browsers can also be used:
- Internet Explorer 11 or greater
New accounts can easily be provisioned for you. Send your Account Manager the first name, last name, and email address of persons needing access.
We need to move our API connection to another machine. Will you need to whitelist our new IP address?
No, we do not need to whitelist your machine. We accept requests from anywhere in the world.
No, each user only needs one auth token for all services.
You can download a list of fields and their descriptions at the Data Dictionary.
Lookup tables can be used to find all mappings. The link to the various lookup tables can be found under Lookups. Some attributes have their own lookup table, such as CBSA Codes, where other attributes with a shorter list of mappings can be found in the Attribute Mappings lookup table.
For customers who display the Infogroup data online or in their products, display restrictions specify what can be displayed and what cannot.
A deprecation date indicates that the value in the lookup table has been retired and is no longer used.
Use a record level note to indicate that the business has requested suppression. Our data associates will need to get confirmation from the business of this request.
If I accidentally hit submit and need to add or update more information, can I cancel or go back into the submission?
No. If you need to add or update more information, create another submission.
If a record is not listed as in business and I suggest changes, do I need to also specify that the business should be changed to in business?
No. If you submit changes to a record that is not listed as in business, our data associates will attempt to verify your changes. If they are able to verify the listing as in business, they will change the record accordingly.
I can’t find an infogroup_id that I know is in your database because I received it in my deliveries. What should I do?
Certain records are hidden in the feedback UI because they have been suppressed for some reason. If you cannot find the record you’re looking for, suggest adding it to our database. All new record suggestions are matched to our database, so if we already have the record, we will match it and update the existing record.
When your submissions are complete, you will see the results column for the submission change from “processing” to a series of 3 numbers. The first number in green represents the number of accepted changes. The middle number in orange represents the number of attributes or fields where no action was taken. The last number in red represents the number of rejected suggestions.
The Results page only shows submissions for 90 days. If you need to save a copy of submissions, make sure you download them within the 90 day window.
Yes, all Data Axle are compressed using gzip. No other compression options are available.
Yes, the files themselves are checked for integrity and assigned an MD5 hash, which is returned in the API response for each file. There is also an automated quality system in Data Axle that reviews each delivery and looks to make sure that the file includes all attributes selected, fill rates correspond to global database fills, and more. In addition to this, we have a fulfillment team that manually checks every delivery for quality.
Large feeds are split into smaller, manageable files with a numeric suffix. Each file maxes out to about a million records.
Once you download all files for your Snapshot, import each file in no particular order into your database to create your combined Snapshot of your subscription.
Incremental Files begin generating right after midnight UTC. File generation times may vary depending on the file size. Weekly Incremental Files begin generating at 12:00am (UTC) every Monday.
Generation of Incremental Files is automatic. If for some reason an Incremental File fails to generate, the system will attempt to re-generate the file every 2 hours until the file is successfully generated.
If you miss consuming one or more generations of the Incremental Files, the files should be imported in chronological order to ensure that you end up with the most current data.
It takes multiple days for us to process the monthly file. What do you recommend for processing the monthly file in relation to the Daily Incremental Files we receive during this time?
Monthly Files are always generated between the 1st and 5th of each month. We recommend processing the monthly file as soon as it is available and then catch up with the Daily Incremental Files. For example, if the monthly file is generated on the 2nd of the month and takes you 3 days to process, we then recommend applying Daily Incremental Files from the 2nd through 5th.
When you call the API for details about a specific subscription, the response includes the list of attributes being delivered and the list of attributes used to signal updates.
Yes, a "begin" and "end" date is delivered with each Incremental File delivery in the API response.
In the API response, each delivery is assigned a batch ID and creation time. Used in combination, these can help you identify a new delivery.
It depends on the frequency of your deliveries. Monthly files are typically available between the 1st and the 5th of each month. Weekly files generate every Monday at midnight UTC. Daily files generate every night at midnight UTC. In general, you should check for new files at most once per hour.
We are able to call the API and return the URLs to the files in S3. However, we are getting an error when trying to download the files. What are we doing wrong?
If using the command line, wrap any URLs in quotes. If you don't, the bash shell will interpret the "&" characters in the URL as shell characters to background a job and not send the entire URL to the curl command.
We are able to download some of the files from S3, but get an error when trying to download the rest of them. What do we need to do to successfully download all of the files?
The File Delivery API creates "signed" URLs that only last an hour. If the URLs expire before you download all the files, then you simply need to call the API endpoint again to get new URLs.
The Search API returns a maximum of 100 records per request while the Scan API allows you to scroll through all records that meet your criteria.
The query parameter is not supported in the Scan API.
Yes, the initial response includes the number of records that meet your criteria and a scroll_id that can be used to return the records.
You cannot make more than 60 queries per 10 seconds. If you go above that, your requests will be blocked until the 10 seconds are up.
Spacing inside quotes can impact your results. Otherwise, spacing does not matter.
No, filters can be applied in any order.
Only requests using the equals parameter are case sensitive.
You can implement wild card searching on your end by programming your search to recognize a specific wild card and use prefix searching in your request.
The Search API is limited to 100 records per request. You can use offsets to return the next 100 records and so on. If you regularly need to return large sets of records, talk to your Account Manager about using the Scan API.
Because Data Axle is a real-time platform, the results of your search will change as records are updated in our database. You may see records added or removed from future responses. In addition, when the same records are returned, they may be returned in a different order. This is because results are by default, sorted by recency (the time the record was last updated). You can change this behavior by applying a sort parameter to your request.
It depends on your use case and volume of suggestions. The Feedback UI requires someone to log in and manually suggest changes. The Submission API should be used for a more automated approach and for large volumes.
The initial response indicating success or failure of the submission should be within 1 second. From there, the submission is routed to our data associates who typically resolve submissions within 24-48 hours.
If sending many submissions through a bulk request, you should allow 24-48 hours before polling the results API. If you plan to send submissions one at a time (for example, if you send a new submission every 5 minutes), you should poll the results API anywhere from once per day to as frequently as you’re sending submissions (for example, every 5 minutes) depending on how frequently you need the results back (accounting for the initial 24-48 hour delay, of course).
The API limits you to 60 submissions per 10 seconds. If you go above that, your submissions will be blocked until the 10 seconds are up.
Yes, but it depends on how big each submission is. We recommend 100 submissions per bulk request.
Yes, the API supports submissions to correct duplicates. This can be done by suggesting a value in the
duplicate_of attribute or by commenting on the
What is the latency between the response and the availability of the updated record in deliveries? Is there a cutoff date for accepted changes to appear in files?
There is no latency between when a record is updated and when it can be delivered through files. Changes only need to be applied before the delivery begins generating.