Secrets API

A secret is a named bundle of key-value pairs, shared across a VPC. Services reference a secret by ID rather than carrying a copy, so rotating a value updates everything that uses it.

Paths are relative to:

https://api.smll.io/api/v1/workspaces/{workspaceID}/vpcs/{vpcID}/secrets

Endpoints

There is no update endpoint. To change a secret, delete it and create it again, or create a new one and repoint the services that use it. The second is safer: nothing breaks between the delete and the create.

Create a secret

curl -s -X POST -H "$AUTH" -H "Content-Type: application/json" \
  -d '{
        "name": "stripe",
        "values": {
          "secret_key": "sk_live_...",
          "webhook_secret": "whsec_..."
        }
      }' \
  "$BASE/workspaces/$WORKSPACE_ID/vpcs/$VPC_ID/secrets"

Values are stored as a Kubernetes secret in the VPC namespace, not in plain text in the platform database.

Referencing a secret from a service

Link an environment variable to one key inside a secret:

curl -s -X PUT -H "$AUTH" -H "Content-Type: application/json" \
  -d '{
        "variables": [
          {"key": "STRIPE_SECRET_KEY", "secret_id": "9f21...", "secret_key": "secret_key"}
        ]
      }' \
  "$BASE/workspaces/$WORKSPACE_ID/vpcs/$VPC_ID/services/$SERVICE_ID/env"

key is the variable name the container sees. secret_id and secret_key say where the value comes from. The value never gets copied onto the service, so it does not appear in service configuration or in the dashboard's environment editor.

This is the right way to hand a service a database password, an S3 secret or a queue token: fetch it once from the resource's connection endpoint, store it in a secret, and reference it everywhere.

Deleting

Deleting a secret does not rewrite the services that reference it. Those references stop resolving, and the affected containers fail to start on their next rollout with a missing-secret error. Repoint the services first, then delete.