Marble 2 beta

Projects and API keys

Projects are the isolation boundary for Marble 2 Developer API work. A project owns its API keys, assets, operations, usage, and optional monthly spend limit.

Create projects around real boundaries

Use a separate project for each production service or environment when you need independent credentials, usage reporting, or budgets. Common layouts are:

  • one project for production and another for development;
  • one project per customer-facing product;
  • one project per cost center or experimental workload.

Create or switch projects from the project control at the top of the Marble sidebar. The selected project controls what the Developers and billing screens manage.

Issue a key

Open Developers, choose API keys, and name the key after the service and environment that will use it. Select the minimum scopes required by that integration.

A typical task worker needs:

text
tasks.createoperations.readassets.createassets.read

Add operations.cancel only if the service exposes cancellation. Add assets.delete only if it owns asset cleanup.

The secret is returned once. Store it immediately in your deployment's secret manager. Never share one key between unrelated applications; separate keys make rotation and last-used auditing useful.

Each key is owned by the person who creates it. The API keys page shows that owner. Removing the owner from a project revokes their active keys in that project; removing them from the account revokes their active keys across all projects. Applications using those keys stop working immediately. Restoring the person's access does not restore revoked keys, so issue replacements when access is granted again.

Control spend per project

Account owners can set a monthly limit for the whole account or for one project. Project-scoped limits let you cap an experiment without interrupting other production work. See Billing for the interaction between credits, alert thresholds, and task admission.

Move an integration safely

Resources do not become cross-project merely because an API key changes. To move a workload:

  1. Create the destination project and key.
  2. Re-upload or recreate required assets in that project.
  3. Deploy the new key and verify a request.
  4. Stop the old workload, revoke its key, and clean up its assets.

Do not copy operation or asset IDs between projects; they remain owned by the project that created them.