Access control & KYC
How restricted destinations and request patterns are gated.
Some destinations and request patterns require approval before use. This may include social and professional networks, search engines, community forums, messaging services, video and live-streaming platforms, employment and recruiting sites, dating services, and adult-content platforms.
Each access-control case returns its own status code so callers can branch on the response:
| Case | Status | Body field | Example |
|---|---|---|---|
| Destination domain not enabled for your organization | 403 Forbidden | reason | Any method against an unapproved hostname |
| Reachable URL but the chosen method requires KYC for that path | 400 Bad Request | error + message (with issues[].field = "url") | POST to a restricted endpoint |
403 — domain not enabled
{ "reason": "Requests to example.com are not allowed. Contact support@usestring.ai for access." }400 — method requires KYC for the path
{
"error": "Validation error",
"message": "POST requests to this path are blocked pending KYC. Email support@usestring.ai with your request to get access.",
"issues": [
{
"field": "url",
"message": "POST requests to this path are blocked pending KYC. Email support@usestring.ai with your request to get access."
}
]
}Requesting access
In either case, email support@usestring.ai with your use case to request access for your organization.
In-session navigation
Access control isn't only applied to the initial URL. When you drive a page with browser actions or the CDP browser, every in-session navigation — clicks, redirects, and script-driven navigations — is re-checked against the same rules.