If you're integrating the CocoCloud Signing API into your own tool, bot, or app, the token you generate is effectively a password to your account's signing capacity. Bearer tokens support scopes and per-token CORS restrictions specifically so you don't have to hand out full account access just to let something sign an IPA. Here's how to actually use that, and a few nuances worth knowing before you ship a key anywhere.

The Four Scopes

Every Bearer token can be limited to exactly what it needs:

  • sign — custom sign, free-enterprise sign, App Library signing, and chunked uploads
  • apps — full App Library CRUD (list, upload, update, delete persisted apps)
  • certs — shared enterprise certificates, certificate/P12/mobileprovision downloads, the cert checker, and the P12 password changer
  • user — includes your account email in /v1/me responses; without it, the field comes back null

All four are enabled by default when you create a token, but you don't have to leave them that way. A bot that only ever calls /v2/free-enterprise/sign doesn't need certs or apps — give it sign only, so a leaked token can't touch your certificates or app library.

If a request hits an endpoint outside its token's scopes, the API returns a plain 403:

{ "error": "This token does not have the 'sign' scope." }

Two Things That Are Easy to Miss

Scope enforcement only applies to Bearer tokens. Legacy X-API-Key: sk_... keys (and normal session/cookie auth) are always unrestricted — there's no scope model for them. If you want a genuinely limited credential, it has to be a Bearer token, not a legacy key.

Tokens created before scopes existed keep full access. If you've had a Bearer token since before this feature shipped, it was grandfathered in with unrestricted access rather than silently broken. If you want that older token actually scoped down, the straightforward move is to create a fresh token with only the scopes you need and retire the old one.

Restricting Where a Token Can Be Used From

If a token is going to be called directly from a browser-based app rather than a server, you can lock it to specific origins on the token's edit page — add the exact origin (e.g. https://yourapp.com) and only requests with a matching Origin header get a CORS-enabled response. You can register up to 10 origins per token. Requests from a server (no Origin header at all) aren't affected by this list either way — it's purely a browser-side control.

Rotating and Revoking

A token's secret is shown exactly once, at creation. There's no "reveal" later — if you lose it, the fix is to create a new token (up to 10 per account) and delete the old one, not to try to recover the original. Practical rotation habits:

  • Give each integration its own token, named for what it's for, rather than reusing one token everywhere. A leak in one integration then doesn't touch the others.
  • Scope each token to the minimum it needs, per the list above.
  • Delete tokens for integrations you've retired — an unused token with standing access is just risk with no upside.

Auditing What a Token Can Actually Do

Rather than trying to remember what you set a token to, ask the API directly:

curl -H "Authorization: Bearer YOUR_TOKEN" https://api.cococloud-signing.vip/v1/me

The response tells you the auth type (bearer vs legacy), the token's name, and its exact scope list, alongside your current usage stats and limits. It's worth calling this once after setting up any new integration just to confirm the token behaves the way you configured it.

Don't Poll With a Broad Token — Use Webhooks

If what you actually want is to know when a certificate gets uploaded, revoked, or an enterprise cert/mobileprovision becomes available, a webhook is a better fit than repeatedly polling with a certs-scoped token. Webhooks (configurable under Developer → Webhooks) can notify a generic HTTPS endpoint, Discord, or Telegram on events like cert.uploaded, cert.revoked, enterprise_cert.available, and enterprise_mp.available, tagged with an X-Webhook-Event header. It's one less place a broadly-scoped token needs to live.

The Short Version

Use Bearer tokens (not legacy keys) whenever you need real access control, scope each one down to what its integration actually calls, restrict origins for anything browser-facing, give every integration its own token so a leak stays contained, and check /v1/me whenever you want ground truth on what a token can do.