The platform, as a package you install.
Official open-source clients for JavaScript and TypeScript, Python, and PHP. Configure one with an API key and a project ID, and work with Cosmoner services through a consistent, language-native API.
- 3 official languages
- 18 permission scopes
- MIT licensed
- HTTP underneath
import { Cosmoner } from "@cosmoner/sdk";const cosmoner = new Cosmoner({ apiKey: process.env.COSMONER_API_KEY, projectId: process.env.COSMONER_PROJECT_ID,});await cosmoner.email.send({ to: "[email protected]", subject: "Your receipt", html: receipt,});
LANGUAGES
3
JS/TS, Python, and PHP
AUTH
API key
Bearer token, per project
SCOPES
18
Read and write, per service
LICENSE
MIT
Source on GitHub
Choose your language
One command, then a client
Install the official package with the package manager you already use. Each one exposes the same client with the same service namespaces.
JavaScript / TypeScript
@cosmoner/sdk
npm install @cosmoner/sdkPython
cosmoner-sdk
pip install cosmoner-sdkPHP
cosmoner/sdk
composer require cosmoner/sdkWhat the client gives you
Built for this platform, not generated from it
The SDKs are developed specifically for Cosmoner, so their API maps onto projects and services rather than onto raw endpoints.
Three official SDKs
Use the Cosmoner client in JavaScript and TypeScript, Python, or PHP, installed with the package manager you already use.
npm · pip · composer
One consistent client
Each SDK exposes a Cosmoner client with service namespaces, so the same structure carries across every supported language.
Same shape, three languages
Project authentication
Configure the client with an API key and project ID. The key decides which project the code reaches and what it may do there.
Authorization: Bearer …
Scoped permissions
Keys are scoped per service and per direction — read or write — so a deploy script does not carry the permission to delete a domain.
apps:read · storage:write · …
Email service support
Send email through the email service namespace with recipients, a subject, HTML content, and your email credential.
Available today
Open source, MIT
Read the implementation, contribute improvements, or fork it for your own integration. The source is on GitHub under the MIT license.
github.com/datablock-dev/sdk
API keys and scopes
Give the key the job, not the keyring
Permissions are split per service and per direction, so a key can be exactly as capable as the thing holding it needs to be — and no more.
- Name a key after what uses it — a CI pipeline, a cron job — not after yourself.
- Omitting permissions creates a full-access key, which is rarely what a deployed service needs.
- A key's scopes can be updated later, so tightening access does not mean reissuing it.
- The same key authenticates docker push and docker pull against the container registry.
{ "name": "CI/CD Key", "permissions": [ "apps:read", "apps:write", "storage:read" ]}
# this key cannot touch domains or membersAuthorization: Bearer <your-api-key>
What it costs
The SDK itself is free
There is no licence, seat, or call charge for the SDK or the API behind it. You pay for the resources you create with it, at the same prices as the control panel.
- The SDK
- USD 0
- Install it in as many projects, environments, and CI pipelines as you like. There is no seat count and no licence to renew.
- API requests
- USD 0
- Reads and writes are not metered. Requests are rate-limited to keep the API healthy, and a throttled call returns a 429 rather than a charge.
- API keys
- USD 0
- Issue and rotate as many scoped keys as you need — a key is an access grant, not a billable resource.
- Resources you create
- Normal price
- An app, server, bucket, or database created through the SDK is billed exactly as one created in the control panel.
Creating a resource through the SDK charges the project's payment method exactly as the control panel does, prorated to the next billing date.
One project
What you can automate
A scoped key reaches one project's resources, which is what makes the SDK safe to put inside a deployment rather than only on your own machine.
Questions worth answering up front
Every scope, header, and endpoint is listed in the API reference and the API key guide.
- What do I need to get started?
- An API key and the ID of the project you want to work with. Install the package, configure the client with both, and the service namespaces are available.
- How should I scope a key?
- To the least it needs. Scopes are per service and split into read and write, so a metrics dashboard gets apps:read while the pipeline that ships code gets apps:write. Omitting permissions creates a key with full access — worth avoiding outside a throwaway script.
- Can I change a key's permissions later?
- Yes. A key's name and permission set can be updated without issuing a new key, so tightening scope does not mean redeploying everything that uses it.
- Do I have to use an SDK?
- No — the API is plain HTTP with a bearer token, so any language works. The SDKs exist to save you writing the request layer, not because the API needs them.
- Does the same key work for docker push?
- Yes. An API key authenticates docker push and docker pull against the Cosmoner container registry as well as the REST API, so CI needs one credential rather than two.
- Which services can I reach?
- The scopes list what a key can address: apps, servers, domains, email, storage, secrets, variables, members, and support. The SDK surface follows the API as it grows.
Open source
Read it before you depend on it
The client is not a black box in your dependency tree. Review how it builds requests, open a pull request, or fork it if your integration needs something different.