This allows adding or changing individual tags without knowing about all the other tags. The client must know the tag IDs to remove or change them.

Internally, the Data Axle will try to match create with existing objects. For tags, matching is performed by finding an existing tag by the SIC Code. For Contacts, it looks for existing records based on the name and email of the contact.

Array attributes

Certain fields contain a collection of values. Updating these fields is a bit more complex than suggesting the new value.

replace, remove, create are the valid keys. If replace is provided, the other options cannot be sent.

Suggesting a new place

Suggesting a new business requires a core set of attributes to be submitted. These attributes are name, street, city, state, zip, and phone. This sample request shows the minimum information required to suggest a new place:

The new business is reviewed by Infogroup to determine if it is correct.

Bulk Requests

POST /api/1/submissions/bulk

The bulk endpoint supports sending many submissions in one request. A request contains a submissions key containing an array of submissions. The following example shows how a new name is suggested for infogroup_id "987765321", and comments on the phone for infogroup_id "430398671".

Additional Submission fields

In addition to suggesting corrections and commenting on attributes for Infogroup to review, each submission supports the following options:

determined_at is used to describe when the information was acquired. For example, if an external system acquired the information on December 24th and did not submit the information until December 25th, then this field would be used. The Submission API defaults determined_at to the current time.

Fields

By default, all available fields are included in the output. This can be changed with the fields option. You can supply any field included in your contract. Browse the list of all fields at the Data Dictionary.

{"fields":["name","street","city","state","postal_code"]}

Scrolling Through Submission Results

Results from the API are ordered chronologically, earliest first. Each request returns up to 100 results at a time. To read the next set of results, use the token from the previous request and append it to the request URL via the since parameter:

curl https://data-axle.com/api/1/submissions/results?since=42

Repeat this process until an empty list of submissions is returned. Store the final returned token, for use in future requests for new results:

{"token":42,"results":[]}

The Submission Result object

For every field submitted in the original submission, the Submission Result provides either an accepted value or a rejected reason.

submission_id - The ID of the submission.

update_type - addition if a new place was created or update for an update to an existing place.

infogroup_id - The Infogroup ID of the created or updated place.

rejected - The list of fields rejected and reasons they were rejected.

current - The current record.

timestamp - The time and date the result was recorded.

comment - An optional comment from the associate who reviewed the submission.

Rejections

The list of rejected fields is in the format of field: [{reason: "reason", message: "rejection reason message"}]:

A field rejection does not mean your entire submission is rejected only the specified fields. When interpreting rejections, only the reason should be interpreted programmatically, as the message is subject to change.

Rejected Submissions

Submissions may be entirely rejected. If rejected, a reason and message will be provided on the "infogroup_id" field:

Rejection Reasons

Applies only to new businesses. It means that an insufficient amount of information was provided to create a new record.

failed_matching

Record

Means that the submission could not be matched to an existing place.

fictitious_place

Record

Applies only to new businesses. It means that the suggested business does not exist in the real world.

fictitious_infogroup_id

Record

Means that the submitted Infogroup ID does not exist in the database.

inaccurate_information

Record

Means that the submission contained too much bad information to be worth rejecting each field.

teleresearch

Both

During a phone call this submission or field was found be invalid.

human_review

Both

This submission or field was rejected during a human review.

missing

Field Level

A required field was missing.

outdated

Field Level

Another submission has modified this field since the submission was made.

teleresearch

Field Level

During a phone call this field was found be invalid.

invalid

Field Level

The field was submitted in an invalid format.

protected

Field Level

The field cannot be updated by the submitter.

Handling duplicates

If the submitted infogroup_id is for a place marked as a duplicate, we automatically redirect the submission to the correct place. The Submission Result API returns the infogroup_id of the correct place.