Project Secrets (CI/CD)

Create, list and revoke the project tokens that let CI/CD pipelines deploy your game.

A project secret is a long-lived token, scoped to a single project, that lets an automated caller (a CI/CD pipeline, a script, another service) act on that project without a human login. You present it to the control plane in the X-Project-Token header, and it authorizes exactly the project it was minted for — for example to upload a build artifact and publish a new version from a GitHub Actions workflow.

Each token is shown once, at creation. Only a one-way hash is stored, so a lost token cannot be recovered — create a new one and revoke the old. There is no "edit": the value is immutable, so the management surface is create, list and delete.

Who can manage secrets

These routes are for logged-in users — authenticate management calls with a developer token in the X-Auth-Token header (issued when you log in via the CLI or console). A X-Project-Token cannot manage secrets, so a leaked CI token can never mint or revoke other tokens. For organization-owned projects, any member may list secrets, but only an owner or admin may create or delete them.

All examples below target the production control plane at https://control-plane.prod.620cloud.com and assume PROJECT_ID is your project's id and AUTH_TOKEN is your developer token.

Create a secret

Mint a new token for the project. The response includes the token exactly once — store it immediately (e.g. as a CI secret).

curl -X POST "https://control-plane.prod.620cloud.com/projects/$PROJECT_ID/secrets" \
  -H "X-Auth-Token: $AUTH_TOKEN"

{
  "secret": "6717f2c1a4e8b90b3c2d1e4f:Hh1Qd8m2Zk0pVtY7Rn4Lx6Bs3Wc5Ja9",
  "id": "6717f2c1a4e8b90b3c2d1e4f",
  "createdAt": "2026-06-16T12:00:00Z"
}

The secret value is the full project token. Use it verbatim as the X-Project-Token header. The id is the part before the : and is what you pass when listing or deleting.

List secrets

Returns metadata only — never the token value or its hash. Use it to audit which tokens exist and when they were created.

curl "https://control-plane.prod.620cloud.com/projects/$PROJECT_ID/secrets" \
  -H "X-Auth-Token: $AUTH_TOKEN"

{
  "items": [
    { "id": "6717f2c1a4e8b90b3c2d1e4f", "createdAt": "2026-06-16T12:00:00Z" }
  ]
}

Delete (revoke) a secret

Revokes a token by id. Once deleted, any caller presenting that X-Project-Token is no longer authenticated.

curl -X DELETE "https://control-plane.prod.620cloud.com/projects/$PROJECT_ID/secrets/$SECRET_ID" \
  -H "X-Auth-Token: $AUTH_TOKEN"

Rotation

There is no update endpoint. To rotate a token, create a new one, update wherever it is used, then delete the old one — overlapping briefly so deploys never break.

Using a secret from CI

Store the created secret as a repository secret (e.g. SIXTWENTY_PROJECT_TOKEN in GitHub Actions), then send it as X-Project-Token on the deploy calls your pipeline makes. For example, requesting an artifact upload URL as part of publishing a new version:

# .github/workflows/deploy.yml
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # ... build your game artifact ...
      - name: Request artifact upload URL
        run: |
          curl "https://control-plane.prod.620cloud.com/projects/${{ vars.SIXTWENTY_PROJECT_ID }}/artifact-upload-url?contentSizeBytes=$(stat -c%s build/game.jar)" \
            -H "X-Project-Token: ${{ secrets.SIXTWENTY_PROJECT_TOKEN }}"
        # ...then upload the artifact and POST /projects/{id}/versions to publish.

A project token is scoped to its single project, so the same token cannot touch any other project — keep one token per pipeline and revoke it the moment it might be exposed.