Supported authentication pattern for calling the SQL Queries API from an RStudio Code Workspace using FOUNDRY_TOKEN / FOUNDRY_PROXY_URL

Ask the Community
1

We are testing the Foundry SQL Queries API from an RStudio Code Workspace and have a working implementation using the Python foundry-platform-sdk through R reticulate.

The working pattern is approximately:

fs <- reticulate::import("foundry_sdk")

token <- Sys.getenv("FOUNDRY_TOKEN")
proxy_url <- Sys.getenv("FOUNDRY_PROXY_URL")

client <- fs$FoundryClient(
  auth = fs$UserTokenAuth(token),
  hostname = proxy_url
)

query_status <- client$sql_queries$SqlQuery$execute(
  query = query,
  fallback_branch_ids = list("T1DEV")
)

query_id <- query_status$query_id

We then poll:

client$sql_queries$SqlQuery$get_status(query_id)

and retrieve the result using:

client$sql_queries$SqlQuery$get_results(query_id)

This is working successfully from the Code Workspace and appears to route the Platform SDK calls through the workspace-provided FOUNDRY_PROXY_URL.

We would like to confirm whether this is an intended and supported authentication pattern for Platform API calls originating from a Code Workspace, rather than relying on an implementation detail.

  1. What is FOUNDRY_TOKEN in a Code Workspace?

    Is FOUNDRY_TOKEN specifically intended to be consumed by user application code and the foundry-platform-sdk, or is it primarily an internal/workspace implementation credential?

  2. What is the expected lifetime of FOUNDRY_TOKEN?

    Is it a short-lived access token associated with the active Code Workspace/user session?

    If so, what is its typical validity period?

  3. Is FOUNDRY_TOKEN automatically refreshed or rotated while the Code Workspace remains active?

    If the token rotates, does the value of the FOUNDRY_TOKEN environment variable itself change, or does the workspace proxy transparently handle refresh/credential replacement?

  4. How should token rotation be handled by a long-running client?

In our current implementation the token is read once when the client is created:

token <- Sys.getenv("FOUNDRY_TOKEN")
client <- fs$FoundryClient(
  auth = fs$UserTokenAuth(token),
  hostname = proxy_url
)

If the Code Workspace credential expires or rotates while the R session remains active, is the existing FoundryClient expected to continue working?

Or should application code periodically reread the workspace credential and recreate the SDK client?

  1. How does this interact with asynchronous SQL Queries API calls?

SqlQuery.execute() returns a query ID and the query can continue running asynchronously.

The client then makes separate authenticated calls to:

GET /api/v2/sqlQueries/{queryId}/getStatus
GET /api/v2/sqlQueries/{queryId}/getResults

What happens if the access token used to submit the query expires before getStatus or getResults is called?

For example:

t0        POST /sqlQueries/execute
          token A valid
          -> query ID returned

t0 + 20m  query still running

t0 + 30m  token A expires / rotates

t0 + 35m  GET /getStatus

Should the status/results request simply be made using a newly issued workspace token?