Service Tags
Every IP observed by Synthient is associated with one or more service tags identifying the proxy provider, VPN, or anonymization service it belongs to. These tags appear in API responses, feed exports, and firehose events.
The total number of tracked providers is higher than what is listed here. Some service tags are classified as TLP:AMBER+STRICT and are only shared with specific organizations under MNDA.
| Provider | Tag | Links |
|---|---|---|
2CAPTCHA | Context | |
360PROXY | Context | |
711PROXY | Context | |
711PROXY_UNLIMITED | Context | |
911FO | Context | |
911FO_NETNUT | Context | |
911PROXY | Context | |
911PROXY_UNLIMITED | Context | |
922PROXY | Context | |
9PROXY | Context |
Use tags in an integration
The tag is the provider identifier used in Synthient data. Use the exact value returned by the API when matching a provider in a rule or joining observations in your own database. Keep a separate display name for your interface rather than deriving a label by changing the identifier.
Provider identity is different from network ownership or an anonymization category. An IP can have multiple observed providers, and a provider tag alone does not describe every request made through that address. Inspect the surrounding fields and timestamps in the IP API response before applying a policy.
Investigate an attribution
Open a provider's public context profile from the table to read the available research. Compare that context with the methodology and risk scoring guidance, especially when an address is shared or observations change over time.
Keep integrations tolerant of provider identifiers added after your application was released. Preserve unfamiliar values for analysis rather than failing an otherwise valid response. If you need help interpreting a tag or its availability in your access level, contact support with a redacted response example.