Getting Started with the CocoCloud Signing API
Everything you can do by hand in the CocoCloud dashboard — upload an IPA, sign it against a certificate, generate an install link — you can also do from a script, a CI pipeline, or your own app, through the CocoCloud Signing API. This post walks through getting a token, picking the right signing endpoint for your use case, and reading back the result.
Base URL
All API requests go to a dedicated subdomain, not the main site:
https://api.cococloud-signing.vipEvery route below is relative to that base — e.g. /v2/customsign means https://api.cococloud-signing.vip/v2/customsign.
Getting a Token
Open Developer → API Keys in your dashboard and create a new token. You get to name it and choose which scopes it can use:
- sign — custom sign, free-enterprise sign, App Library signing, chunked uploads
- apps — full App Library access (upload, list, update, delete)
- certs — shared enterprise certs, certificate/P12/mobileprovision downloads, cert checker, P12 password changer
- user — includes your account email in
/v1/meresponses
All four are checked by default, and the token secret is shown once, at creation time — copy it somewhere safe immediately, because the dashboard won't show it again. You can hold up to 10 active tokens per account. (We go deeper on scopes, rotation, and locking a token down in the follow-up security post.)
Send it as a Bearer token on every request:
curl -H "Authorization: Bearer YOUR_TOKEN" https://api.cococloud-signing.vip/v1/meA legacy X-API-Key: sk_... header (or a bare ?sk_... query string) also works for older integrations, but Bearer tokens are the recommended path going forward since they support scopes and per-token CORS origins.
Three Ways to Sign an IPA
Which endpoint you want depends on what you're building:
| Endpoint | Use case |
|---|---|
POST /v2/free-enterprise/sign | Fastest path — no certificate needed, signs against CocoCloud's shared enterprise cert |
POST /v2/customsign | Sign with your own certificate and provisioning profile |
POST /v2/apps/{id}/sign | Persistent app library — upload once, re-sign and share repeatedly |
Free Enterprise Sign
The quickest way to get a working IPA back:
curl -X POST https://api.cococloud-signing.vip/v2/free-enterprise/sign \
-H "X-API-Key: YOUR_KEY" \
-F "[email protected]"Custom Sign
Bring your own certificate and provisioning profile:
curl -X POST https://api.cococloud-signing.vip/v2/customsign \
-H "X-API-Key: YOUR_KEY" \
-F "[email protected]" \
-F "[email protected]" \
-F "[email protected]" \
-F "password=your_p12_password"A few conveniences worth knowing about here:
- If you've already uploaded a certificate to your account, pass
user_cert_idinstead ofcert/provision/passwordand it'll reuse that saved cert. ipacan be a URL instead of an uploaded file — CocoCloud will fetch it for you.- Optional params:
bundleId,bundleName,bundle_version,random_bundle_id(auto-generate a fresh bundle ID),remove_prov, andipa_compression(0–9).
What You Get Back
Both signing endpoints return roughly the same shape:
{
"success": true,
"jobId": "…",
"downloadUrl": "…",
"manifestUrl": "…",
"itmsServicesUrl": "itms-services://?action=download-manifest&url=…",
"installUrl": "https://cococloud-signing.vip/ota/….plist",
"signingTime": "0.12s",
"appInfo": { "bundleId": "…", "bundleName": "…", "bundleVersion": "…" },
"appSize": { "input": "14.21 MB", "output": "14.22 MB" }
}itmsServicesUrl is the direct itms-services:// install link for Safari. installUrl is a plain HTTPS link that redirects into that same protocol — useful when you're sharing an install link somewhere that strips or blocks custom URL schemes, like Discord or Telegram.
App Library: Upload Once, Sign Repeatedly
If you want an app to persist beyond a single signing job — so you can re-sign it later, share it, or manage it from a script — use the App Library endpoints instead of a one-shot sign:
curl -X POST https://api.cococloud-signing.vip/v2/apps/upload \
-H "X-API-Key: YOUR_KEY" \
-F "[email protected]" -F "access_status=1" -F "expiry_duration=30d"
curl -X POST https://api.cococloud-signing.vip/v2/apps/APP_ID/sign \
-H "X-API-Key: YOUR_KEY"
curl -X POST "https://api.cococloud-signing.vip/v2/apps/APP_ID/download-link?expires=18000" \
-H "X-API-Key: YOUR_KEY"That last call generates a time-limited download link (up to 5 hours) that doesn't require an API key to use — handy for handing an install link to someone else without sharing your credentials.
Know Your Limits Without Guessing
Upload size, storage quota, and monthly signing requests all depend on your plan, and they're configurable on our end — so rather than us printing numbers here that could drift out of date, call the identity endpoint and read them straight from the source:
curl -H "Authorization: Bearer YOUR_TOKEN" https://api.cococloud-signing.vip/v1/meThe response includes your current signing/upload/storage limits and usage stats, plus which auth type and scopes the request used. Every signing response also carries X-Plan-Type and X-Plan-Limit headers, so you can check plan status inline without an extra request. Pro accounts get higher ceilings across the board, unlimited monthly signing requests, Copy-to-Library, and unlimited AltStore-style repos (more on those in our repo sharing guide).
Where to Go Next
This covers the core signing flow, but the full API reference — chunked uploads for large files, webhooks, shared enterprise certificates, and every parameter in detail — lives in the developer docs. If you're integrating the API into a public tool or app, read the token scopes and security post next before you ship a key anywhere.
Comments (0)