Infringement.Report's reverse image search API provides industry leading data that provides more comprehensive results than other search engines.
Infringement.Report is an API-first application - the API is always developed first, then the UI is built on top of that functionality. This means that every UI action is done via the API, and you are able to replicate everything to build your own frontend to our service.
In leiu of an official SDK, we have released our app's source code. We're hoping that this will allow you to see what's going on under the hood, and quickly work out how we use the API to achieve our app's functionality. We're also happy for you to take our source and create a clone of Infringement.Report - fork the repo on Github. The source code is licensed under the MIT license (use it however you like, but we accept no liability and provide no warranties).
To enable quick integrations and prototyping, we are actively developing a Zapier app which provides you access to most of the functionality of our API via an easy WYSIWYG interface. Try the Zapier app
While it is inevitable that our services and data structures will change, we maintain a strict "no breaking changes" policy. Any breaking changes that we need to make are announced 12 months ahead of time: We release replacement functionality/data under a new API version, deprecate the old functionality, and sunset it after 12 months (or when usage decreases to zero). This policy gives you the confidence that changes to the API will not randomly break your integrations without notice. Read our full versioning and lifecycle policy
Unless otherwise stated, you must authenticate all requests that you make to the API. This is done by passing your API key in the "X-API-Key" HTTP header. For instance:
POST /3.0/search HTTP/1.1
Host: api.infringement.report
X-Api-Key: 123456789abcdef
To get data about websites who are using your images, you must create a search. A search is a request where you send one or more images to the API, so that our system can find the websites using them. Depending on the amount of images you send, their popularity across the internet (images used on more websites take longer to search), and the current load on the system, it could take several seconds for us to complete a search.
Because of the way that these search engines work, usages can be found even if the image has been renamed or edited, making this data critical for copyright enforcement firms. For monitored lists of images, we verify that the found image is online and score it for similarity against the source image (to help detect false positives), however this must be manually activated for one-off searches. Please be aware that monitored images tend to get more comprehensive results in the long term than a single one-off search.
All searches create an image list, even if only one image is submitted. We will provide a list_id within the search response, and you can optionally set a label to help you identify the images inside the list.
This endpoint accepts the following parameters:
Endpoint: https://api.infringement.report/3.0/search
{
"images": [
"http://www.domain.com/image.jpg",
"https://www.reg.io/img/2342.png?sec=123321"
],
"list_label": "My test list"
}
{
"status": true,
"result": {
"list_id": 713642,
"list_label": "My test list"
"images": {
"count": 2,
"images": [
{
"image_id": 1234567,
"image_url": "https://www.domain.com/image.jpg"
},
{
"image_id": 1234568,
"image_url": "https://www.reg.io/img/2342.png?sec=123321"
}
]
}
}
}
When you start a search, the API will immediately respond to your request with a list_id and the search will be completed in the background. You can then poll the list resource (/list or /list/{list_id}) until it returns search_in_progress=0. Alternatively you can begin polling the /list/{list_id}/query endpoint until it responds with search data. Note: /query will begin to return data as soon as it is available, even if some image searches have not completed yet.
After a search has completed, the result data will be saved and becomes queryable through the /list/{list_id}/query endpoint. There are several manipulations that you can do to the data.
You can specify the sorting of results by passing the "sort" parameter with the name of the metric you want to sort by, and "asc" or "desc". For instance:
By default, we will return 50 results per request, so you will need to use pagination to get all results for a large list of images. To do this you should pass the parameters "rows" (number of rows per page) and "start" (the start row of this page).
The maximum "rows" value is 1000. The query endpoint is realistically designed to be used for real time analysis and may not be suitable for getting all results for a given search. If you wish to export the complete result set in one request, you should use the /export endpoint.
Rather than page through several requests to gather all data in a result set, it is easier to generate an export of all results. This export can be in CSV, JSON, or JSON line format.
Filtering data to match specific requirements is easy.
Filters are applied to your results by specifying a metric name, an operator, and a value.
Filters must be specified in JSON object using '[metric]-[operator]' as the key. An example of a filter is: {"host-cont":"domain.com"} (host contains "domain.com")
| title | string | eql, cont, starts, ends |
|---|---|---|
| language | string | eql, cont, starts, ends |
| description | string | eql, cont, starts, ends |
| url | string | eql, cont, starts, ends |
| host | string | eql, cont, starts, ends |
| protocol | string | eql, cont, starts, ends |
| image_url | string | eql, cont, starts, ends |
| image_width | number | gt, lt, eql |
| image_height | number | gt, lt, eql |
| image_width_on_page | number | gt lt, eql |
| image_height_on_page | number | gt, lt, eql |
| image_id | number | gt, lt, eql |
| found_timestamp | date | before, after, between |
| Operator | Means | Use on Metric Type |
|---|---|---|
| eql | Equals | string, number |
| cont | Contains | string |
| starts | Starts with | string |
| ends | Ends with | string |
| gt | Greater Than | number |
| lt | Equals | number |
| before | Before date | date |
| after | After date | date |
| between | Between two dates | date |
{
"query":{
"filter":{
"url-cont":"domain",
"title-ends":"Brand"
"image_width-gt":1000,
"search_timestamp-between":"2017-10-01T01:01:01Z TO 2017-11-01T01:01:01Z"
}
}
Previously, we allowed Lucene query syntax for advanced queries. This has been deprecated and will be sunset on 1 July 2019. We will soon release an alternative advanced filtering syntax.
Lists are collections of images and image search results. A list can contain one or more images, and is broadly used for querying results and firing notifications.
Lists are controlled via a standard REST endpoint which accepts GET (read list properties or retrieve a list of lists), POST (create new list), PATCH (update existing list), and DELETE (delete list and all data). For more information about lists or their properties, see the API documentation.
Notifications of new domains found in lists can be sent up to daily - we can send either an email or a POST request to a public URL, containing data in a variety of formats.
Notifications can be sent up to once per day, and can be run on an entire list, or only a subset of results (via filters).
Notifications are controlled via a standard REST endpoint which accepts GET (read notification properties or retrieve a list of notifications), POST (create new notification), PATCH (update existing notification), and DELETE (delete a notification). For more information about lists or their properties, see the API documentation.