Build your first kkbase integration.

Create a project, issue a permission-scoped key, and store JSON records through one authenticated HTTPS API.

Five-minute quickstart

1. Create and verify your account.
2. Create a project in the customer portal.
3. Generate a key with database.read and, when needed, database.write.
4. Copy the project slug and send your first request.

curl -X POST \
  https://kkbase.kkboss.com/v1/cloud/PROJECT/data/orders \
  -H "Authorization: Bearer YOUR_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{"data":{"status":"paid","total":89}}'

A successful create returns HTTP 201 with the record ID and stored data.

Authentication

Project API requests use a bearer key. Keys are shown once, can be revoked, and should receive only the permissions they need.

Authorization: Bearer YOUR_SECRET_KEY

Records API

GET    /v1/cloud/{project}/data/{collection}
POST   /v1/cloud/{project}/data/{collection}
PUT    /v1/cloud/{project}/data/{collection}/{record_id}
DELETE /v1/cloud/{project}/data/{collection}/{record_id}

POST and PUT bodies use {"data": {...}}. Collection names begin with a lowercase letter and should contain lowercase letters, numbers, or underscores.

Data access boundary

kkbase stores records in managed PostgreSQL, in a database of its own for each project. Redis remains on the private server network and is not published at all. Applications connect through the authenticated HTTPS JSON API, or directly to their own project database over TLS through the connection pooler on port 6543, where standard connection strings and any PostgreSQL client or ORM work. What is not offered is the database server’s own port: the pooler is the only route in, it only accepts the project’s own role, and that role cannot reach another project’s database or the control plane.

Storage API

Files live in buckets that belong to one project, and are reached with the same project API key as the records. A key needs storage.read to list, fetch or sign, and storage.write to store or delete, so a key handed to a browser can be given the first without the second.

GET    /v1/cloud/{project}/storage
GET    /v1/cloud/{project}/storage/{bucket}?prefix=&limit=&offset=
POST   /v1/cloud/{project}/storage/{bucket}/{path}
GET    /v1/cloud/{project}/storage/{bucket}/{path}
DELETE /v1/cloud/{project}/storage/{bucket}/{path}
POST   /v1/cloud/{project}/storage-sign/{bucket}/{path}?expires_in=
GET    /v1/cloud/signed-storage?token=

An upload is the raw object as the request body, or a multipart form with a file part. An object is addressed by path, so a folder structure is free; re-storing a path replaces that object rather than adding a second one, and each object is counted once against the plan. A bucket is public or private: a private object is read with a key, or with a signed link, which names one object and stops working when it expires. Objects are capped at 25 MB unless the bucket sets its own ceiling.

Buckets are created and removed in the customer portal, not here — the application owns the objects and the portal owns the shape of the storage. A bucket must be empty before it can be deleted. What is not offered is an S3-compatible endpoint: the API above is the way in, so S3 tooling needs a client written against it.

Errors

Use the HTTP status and JSON detail field to handle failures. Common responses include 401 for missing credentials, 403 for insufficient permission, 404 for an unknown resource, 409 for a conflicting state, 422 for invalid input, and 429 when a quota is reached.

Limits and backups

Request, storage, application, AI, and retention allowances depend on the selected plan and are shown before purchase. CSV or JSON imports accept up to 5 MB and 5,000 records per transactional batch. Daily backups cover JSON API records and linked static app files; they are not continuous backups or point-in-time PostgreSQL recovery.

Security checklist

• Keep secret keys on trusted servers.
• Issue separate keys per integration and environment.
• Grant the minimum required permissions.
• Revoke and replace a key when exposure is suspected.
• Allow only exact HTTPS frontend origins.

Support and operations

Check service status, review the current service scope, or open a ticket from the customer portal.