API Resolver Caching

Overview

We strongly recommend using the timestamp/date in your resolver config attributes because there is no guarantee that events always come in "real-time.” Some reporters send their reports with a delay; sometimes, queues can build up in AbuseHQ. And we strongly recommend giving a caching timespan as big as your system allows it to be.

Example

(The time this event arrives at AbuseHQ doesn't matter! Let's say it's 2020-11-29T22:00:00Z) an event comes in and includes the IP 10.0.0.2 and the timestamp 2020-11-29T08:00:00Z

Both the IP and the timestamp are sent to the resolver.

The resolver responds with:

{
  "subscriber": {
    "id": 111111,
    "resolver_data": {
      [...]
    }
  },
  "contract": {
    [...]
  },
  "result_valid_from": "2020-11-29T02:00:00Z",
  "result_valid_until": "2020-11-29T12:00:00Z"
}

NOTE:

"result_valid_from": "[YYYY]-[MM]-[DD]T[hh]:[mm]:[ss]Z",
"result_valid_until": "[YYYY]-[MM]-[DD]T[hh]:[mm]:[ss]Z"

This result is added to the cache, and every following event with the same IP and timestamp between 02:00 and 12:00 on 11-29 will not be queried again!

Learn more

If you want to read about AbuseHQ Data Structure, we recommend reading this article: Understanding The AbuseHQ Data Structure.

• What Is Inbound Processing and Why Is It Important?

• How to Use Inbound Processing

• Why You Need AbuseHQ’s Inbound Processing Capabilities

• CRM Integration Through API - Subscriber Resolver

• Subscriber resolving via X-Header

• Ubersmith Resolver Guide