QUESTION

Why am I getting a Response not successful: Received status code 403 error when running a query in Panther's Data Explorer, even though simpler queries against the same table succeed?

ANSWER

If you receive a 403 Forbidden error when running a query in Data Explorer where the results area shows {"message": "Forbidden"} with no further detail, and simpler queries against the same table succeed, this means the query was rejected before it reached Snowflake. This typically happens when the query contains a SQL syntax error caused by incorrect single-quote escaping inside a string literal.

Root cause

In Snowflake SQL, a literal single quote inside a single-quoted string must be escaped by doubling it (''). Using a backslash escape (\') is not valid Snowflake SQL syntax — it causes the string to terminate early, leaving the remaining characters as bare, unquoted SQL tokens. The malformed query is then rejected at the input validation layer with a 403.

This most commonly appears in REGEXP_SUBSTR_ALL or similar regex pattern strings. For example:

-- ❌ Invalid: backslash-escaped quote terminates the string early
REGEXP_SUBSTR_ALL(
    some_field::STRING,
    'https?://[A-Za-z0-9._~:/?#\\[\\]@!\'()*+,;=%-]+'
)

In the pattern above, the \' closes the string literal at the apostrophe. Everything after it — ()*+,;=%-]+ — is treated as bare SQL, which causes the query to be malformed and rejected.

To resolve this, replace \' with '' (two single quotes) to correctly escape the apostrophe in Snowflake SQL:

-- ✅ Valid: double single-quote escaping
REGEXP_SUBSTR_ALL(
    some_field::STRING,
    'https?://[A-Za-z0-9._~:/?#\\[\\]@!''()*+,;=%-]+'
)

Alternatively, a simpler regex pattern can be utilized if the apostrophe is not required in your character class:

-- ✅ Also valid: simplified pattern without the apostrophe
REGEXP_SUBSTR_ALL(
    some_field::STRING,
    'https?://[A-Za-z0-9._~:/?#%@!:;,=+*()-]+'
)

Tip: To isolate the cause of a 403 error in a complex query, try removing clauses one at a time to identify which part of the query is triggering the issue. You can also test a basic query like SELECT * FROM <your_table> LIMIT 1 to confirm that the table itself is accessible and the issue is specific to the query syntax.