API Reference

DPS has two API surfaces on https://api.duabaforge.com:

Cloud functions at /parse/functions/<name> — what the dashboard calls. Business logic lives in Parse Cloud Functions, called with a signed-in user’s session.
REST under /api/v1 — for automation (CI, build scripts), authenticated with a deploy token instead of a session.

Cloud functions

Making requests


curl -X POST https://api.duabaforge.com/parse/functions/getCurrentUser \
  -H "X-Parse-Application-Id: <DPS app id>" \
  -H "X-Parse-Session-Token: <session token>" \
  -H "Content-Type: application/json" \
  -d '{}'


import Parse from 'parse';
 
Parse.initialize('<DPS app id>', '<DPS JavaScript key>');
Parse.serverURL = 'https://api.duabaforge.com/parse';
 
await Parse.User.logIn(email, password);
const projects = await Parse.Cloud.run('listProjects');

To check a subscription from your own app, use the typed @duabalabs/dps-client rather than raw calls.

Authentication

Almost every function needs a session token (X-Parse-Session-Token), obtained by signing in (loginWithEmail, or Parse.User.logIn). The functions check your access themselves.

Roles on an app. Your role on an app comes from the project: its owner (or the app’s creator), or your role as a team or organisation member.

Action	Roles allowed
Read	owner, admin, developer, viewer
Write, build, publish, manage signing credentials	owner, admin, developer
Secrets, delete, billing	owner, admin

Below owner and admin, secret values (keys, database URIs, passwords) come back masked.

Errors

Errors use Parse’s format:


{ "code": 141, "error": "…" }

Code	Meaning
101	Object not found, or invalid credentials
102	Invalid query (for example, filtering on a protected field)
119	Operation forbidden — your role doesn’t allow it
141	Cloud function error
142	Validation failed

Rate limits

Limits are per IP address and cover sign-in and account operations only:

Endpoint	Limit
`loginWithEmail`, `/parse/login`	10 failed attempts per 15 minutes
`registerUser`, `/parse/users`	10 per hour
`/parse/requestPasswordReset`, `/parse/verificationEmailRequest`	20 per 10 minutes

Going over returns HTTP 429.

Common functions

Account

Function	Purpose
`loginWithEmail`	Sign in with email and password
`registerUser`	Create an account — public sign-ups are currently closed
`getCurrentUser`	The signed-in user

Organisations

Function	Purpose
`createOrganization`, `getOrganization`, `updateOrganization`, `deleteOrganization`	Manage an organisation
`listOrganizations`	Organisations you belong to
`inviteOrganizationMember`, `removeOrganizationMember`, `listOrganizationMembers`	Members

Projects

Function	Purpose
`createProject`, `getProject`, `updateProject`, `deleteProject`	Manage a project
`listProjects`	Projects you can see

Apps

Function	Purpose
`dps_createApp`, `dps_getApp`, `dps_updateApp`, `dps_deleteApp`	Manage an app
`listApps`	Apps in a project

Plans and subscriptions

Function	Purpose
`dps_tiers_list`	The plans and their limits (Pricing)
`dps_subscriptions_check`	Whether an email has an active subscription for an app (`appId`, `email`). Nothing records subscriptions in DPS today, so it answers `active: false` — check a subscription with Sellub instead

DPS has no checkout or payment functions — payments are taken through Sellub.

REST API (deploy tokens)

Create a token under Account settings → Deploy tokens in the dashboard. A token is shown once; it starts with dps_. Send it as a bearer token:


curl https://api.duabaforge.com/api/v1/whoami \
  -H "Authorization: Bearer dps_xxxxxxxx"

Each token carries scopes, and can be limited to one project or one app.

Endpoint	Scope	Purpose
`GET /api/v1/whoami`	—	The token’s identity and scopes
`POST /api/v1/artifacts/upload-url`	`artifact:upload`	Start an upload; returns an `artifactId` and a presigned URL to `PUT` the file to
`POST /api/v1/artifacts/{id}/finalize`	`artifact:upload`	Finish an upload with its SHA-256 and size; DPS verifies it
`POST /api/v1/artifacts/register`	`artifact:upload`	Register a build hosted elsewhere, by URL
`GET /api/v1/artifacts`	`artifact:read`	List an app’s artifacts
`POST /api/v1/releases`	`release:create`	Create a release from artifacts
`GET /api/v1/releases`	`release:read`	List releases
`POST /api/v1/releases/{id}/publish`	`release:publish`	Publish a release to a store
`POST /api/v1/releases/{id}/rollback`	`release:rollback`	Roll a release back
`POST /api/v1/repo/validate`	`repo:read`	Check whether the app’s repo is ready for managed builds
`GET /api/v1/repo/status`	`repo:read`	The last check’s result
`POST /api/v1/builds/dispatch`	`build:trigger`	Start a managed build in the app’s repo
`GET /api/v1/server-app/repo/status`	`repo:read`	A Server App repo’s last compatibility check
`POST /api/v1/server-app/repo/validate`	`repo:read`	Check a Server App repo
`POST /api/v1/server-app/metadata/extract`	`repo:read`	What DPS reads from the repo (classes, functions, routes)
`POST /api/v1/server-app/repo/scaffold`	`repo:write`	Commit DPS’s Server App files to the repo (on a migration branch by default)
`GET /api/v1/server-app/frontend-binding`	`repo:read`	The URLs and public keys a web or mobile client needs

A token can carry repo:write only if its maker may change the app (owner, admin or developer).

The build workflow DPS writes into your repo uses the same token (as the DPS_TOKEN secret) — see Mobile builds & releases.