If an IP is available in the event (as parsed from the report or supplied by a domain resolver) the subscriber id is set to that IP. If not, the event is marked as/stays unresolved.

If an `X-AbuseHQ-Resolve` header was set in the reported email its value will be parsed and subscriber id, contract id, and resolver data will be set.

The most powerful resolver sends queries to a given endpoint and expects a response in a certain format. It will then set the subscriber id, contract id, and resolver data accordingly.

That URL will be called when an event goes through the resolver

HTTP method to be used. When GET is used, the parameters will be added as query params, when POST is used the Content-Type determines how the parameters will be encoded in the body.

When POST is used the content-type determines how the parameters are encoded in the body of the request.

They will be sent to the API. Key names are custom and values can be chosen from using a list of fields. Values are then extracted from the event depending on the chosen field. `client` is the subscriber id in the case that the event was resolved through some other resolver at an earlier point.

The front end offers a button to test the API resolver using some sample data, without having to take the configuration live. The request will come from the same IPs that they will come from in production. See

https://docs.abusix.com/general/outgoing-ips

Allows setting a custom static id to events going through this resolver.

The string that the subscriber id will be set to

If the report contains email evidence and that email contains a from header its value will be used as the subscriber id.

If a domain or URL was parsed from the report it will be used to extract a domain. Further post-processors can then change the extracted value.

Given processors will be applied after a domain is extracted. For this resolver only the `resolve_to_ip` processor is available. It allows resolving extracted domains to an IP by doing a DNS lookup. Note that the DNS records might have changed since the abuse incident happened and thus the resolved IP might not be correctly identifying the source of abuse that is reported.

If the report contains email evidence and that email contains one of the given headers its value will be used as the subscriber id. The headers will be checked in the given order and post-processors will be applied after value extraction.

A list of user-defined header keys that are searched in the given order.

Given processors will be applied after a header value is extracted. They allow decoding base64 content and extracting domains, email addresses, and domains.

If the report contains email evidence and that email contains one of the given headers its value will be used as the subscriber id. The headers will be checked in the given order and post-processors will be applied after value extraction.

An event currently has multiple resource-parts with key-value pairs. You can choose one of them. The incident part and evidence part correspond to the parts shown on the event detail page on AbuseHQ's web front end.

The keys to look for in the given order. (Similar to Headerlist Resolver)

Given processors will be applied after a header value is extracted. They allow decoding base64 content, normalizing email addresses, and extracting domains, email addresses, and domains.