Ownership and external attribution

Every MIOSA resource accepts canonical ownership fields and optional attribution fields:

Field	Meaning
`workspace_id` / `workspace_slug`	The MIOSA workspace that owns the resource
`project_id` / `project_slug`	The MIOSA project that owns the resource
`external_workspace_id`	Your customer’s account / tenant ID
`external_user_id`	The end-user inside that account
`external_project_id`	The project or app ID in your own database

Every resource also accepts a free-form metadata object (up to 16 key-value string pairs). Use it to carry application-layer context - feature flags, plan tier, region, whatever your billing system needs - without bloating your own database with a MIOSA resource join.

Integrators use these fields for four main purposes:

Usage rollup - query GET /api/v1/sandboxes?external_workspace_id=acme-co to aggregate compute time and costs for a downstream customer.
Per-end-user quotas - enforce your own rate limits by counting active sandboxes per external_user_id before creating a new one.
Audit log filtering - the audit log accepts external_user_id and external_project_id as filters so you can pull a customer-specific activity trail without exposing other customers’ data.
Chargeback and billing - external_workspace_id is the recommended key for billing rollup when you resell MIOSA compute to downstream customers. See the Audit Log and Quotas references.

MIOSA stores canonical workspace_id and project_id on each resource. The external fields are stored as opaque strings. Both appear on list/read responses, and list endpoints accept them as filters:

Filtering is always scoped to your MIOSA organization. You cannot see another organization’s resources regardless of what workspace, project, or external IDs you pass.

See Ownership and Attribution for the full filter spec and billing split by workspace/project.

Ownership and Attribution How white-label platforms scope customers, projects, and resources.