Get sandbox details.
The response includes owner_id — the opaque identifier you supplied
at creation time. Use it to map this sandbox back to the corresponding
end-user record in your own system (e.g., your users.id). user_id
in the response is the Copass platform account that holds the sandbox,
not your end-user.
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Successful Response
The Copass platform account that holds this sandbox (derived from the authenticated API key / JWT). This is the Copass-side tenant ID and is also the Vitess shard-routing key — it is NOT the identifier of your end-user. Use owner_id for that.
The same opaque identifier you passed on create — echoed back so you can map this sandbox to the end-user in your system (e.g., your users.id). Copass stores but never interprets it. Two common patterns: (1) set owner_id to your internal user UUID so one Copass account can host many of your users, each with isolated sandboxes; (2) call GET /sandboxes?owner_id=... to list every sandbox that belongs to a given user on your side.
platform_s3 or custom_s3
Tier-derived quotas
Caller's access level on this sandbox: 'owner', 'editor', or 'viewer'. Omitted in legacy owner-only listings; populated by GET /sandboxes once connection-union is wired.
True if the authenticated caller accesses this sandbox via a sandbox_connections grant rather than direct ownership.