API reference

The API is REST over HTTP, with JSON in both directions. Every path below hangs off one base URL, and every authenticated call carries one header.

It is the same API the dashboard itself runs on: the customer surface is everything under /api/public, and the dashboard gets at it through no faster private door. Two routes are the exception — listing your workspaces, and adding a member — because they identify a person rather than a workspace, and a key is not a person. Authentication below says exactly what that means for you.

https://api.mmoall.com/api/public

• Create projects, link a Git repository, and delete a project along with everything it deployed.
• Set and remove environment variables per environment. They are encrypted at rest and never read back.
• Trigger a deploy, poll the build, and read or live-stream its logs.
• Attach a custom domain and verify it over DNS.
• Drive the firewall: policies, rules, IP allow/deny lists, and the event log.
• Read traffic, error rate, latency, visitors and page views.

Routes exist that this page deliberately leaves out: the admin console, the build-agent fleet, and the Git webhooks a provider calls. They are not customer surface, they carry no compatibility promise, and an API key cannot reach them.

Every route below, except the catalog, needs an API key sent as a bearer token:

Authorization: Bearer mmt_Yk9uZTMyLWJ5dGVzLW9mLXJhbmRvbW5lc3M

Keys are created in the dashboard, on the API Keys page.

• A key is mmt_ followed by 32 random bytes in base64url.
• The full key is shown exactly once, at creation. Copy it then — we cannot show it to you a second time.
• We store only a SHA-256 hash of it, so a breach of our database does not hand anyone your keys.
• Revoking takes effect on the very next request: every call re-reads the key from the database, and there is no cache to wait out.

Since a key cannot list your workspaces, you have to know your workspaceId up front. The dashboard reads it with your login session, so the quickest way to see it is to call that same route from a browser you are signed in to Mmoall in — a bearer token will not work there. Otherwise: any project you fetch carries its workspaceId in the response.

GET https://api.mmoall.com/api/public/workspaces
  ← login session   200  [{ "id": 1, "name": "acme", … }]
  ← bearer token    401  UNAUTHORIZED   // a key is not a user

From a fresh key to a running deploy, in four calls. Export the key as MMOALL_TOKEN first. The ids below are examples — use your own.

1. Find a project. Doubles as proof that the key works. workspaceId is required.

curl -s "https://api.mmoall.com/api/public/projects?workspaceId=1" \
  -H "Authorization: Bearer $MMOALL_TOKEN"

2. Set a secret. Encrypted before it is written, overwriting whatever was there. No route ever reads it back.

curl -s -X PUT \
  "https://api.mmoall.com/api/public/projects/42/environments/production/env-vars/DATABASE_URL" \
  -H "Authorization: Bearer $MMOALL_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"value":"postgres://…"}'

3. Deploy. Answers 201 with the new build — including the id you need next.

curl -s -X POST "https://api.mmoall.com/api/public/projects/42/builds" \
  -H "Authorization: Bearer $MMOALL_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"branch":"main"}'

4. Watch it build. Server-Sent Events, live until the build finishes.

curl -N "https://api.mmoall.com/api/public/builds/1001/logs/stream" \
  -H "Authorization: Bearer $MMOALL_TOKEN"

Every successful JSON response is wrapped in a data field. Unwrap it once, and what is inside is the shape the endpoint documents.

{
  "data": {
    "id": 42,
    "name": "storefront"
  }
}

• A 2xx with a body is always { "data": … } — whether data holds an object or an array.
• A 204 has no body at all. Deletes and environment-variable writes answer this way.
• Send Content-Type: application/json on POST and PUT. Anything else answers 415.
• Send Accept-Language: vi (or en) and error messages come back in that language. Field names and codes never change.
• Ids are integers. Timestamps are ISO-8601, in UTC.

Exactly one route is paginated: the firewall event log. It answers with a page object inside the usual envelope, where number is the 0-based page index. Every other list route hands back the whole array.

{
  "data": {
    "content": [ /* … */ ],
    "totalElements": 137,
    "totalPages": 3,
    "number": 0,
    "size": 50,
    "first": true,
    "last": false
  }
}

Errors are RFC 7807 problem documents, not the data envelope. The HTTP status gives the class of failure; the code field names the exact one.

{
  "type": "about:blank",
  "title": "Validation failed",
  "status": 400,
  "detail": "One or more fields are invalid.",
  "code": "VALIDATION_FAILED",
  "errors": {
    "name": "must not be blank"
  }
}

Branch on code, never on title or detail — those are prose, they are translated, and they get reworded. The errors object appears only on VALIDATION_FAILED, mapping each rejected field to its reason.

404 NOT_FOUND is also the answer for a resource that exists but is not yours — see “One key, one workspace” above. It is not a bug, and retrying will never turn it into a 403.

There is no rate limit on this API today. We do not throttle, meter or reject calls for arriving too fast — no such filter is deployed. We would rather write that down than publish a limit we do not enforce.

That is a fact about today, not a promise for ever. A rate limit is an ordinary thing for a platform to add, and if we add one it will answer 429 and be documented here before it is switched on. So do not build a client that leans on its absence: back off when a call fails, and stream a build log rather than polling it in a tight loop.

Plan caps are a different thing, and they are real: seats, firewall rules and IP rules are limited per plan, and going over answers 409 with SEAT_LIMIT_EXCEEDED or PLAN_LIMIT_EXCEEDED. The rate-limit rules you can configure in the firewall are a third thing again — those limit your visitors, not your API calls.

The keys of one workspace. You can manage them in the dashboard too — these routes exist so a key can be rotated from CI without a human.

Response

// POST → CreatedApiTokenView — the only response that ever carries `token`
{
  "id": 7,
  "name": "ci-deploy",
  "prefix": "mmt_Yk9uZTMy",
  "token": "mmt_Yk9uZTMyLWJ5dGVzLW9mLXJhbmRvbW5lc3M",
  "createdAt": "2026-07-14T09:12:00Z"
}

// GET → ApiTokenView[]
{
  "id": 7,
  "name": "ci-deploy",
  "prefix": "mmt_Yk9uZTMy",
  "createdAt": "2026-07-14T09:12:00Z",
  "lastUsedAt": "2026-07-14T11:40:03Z",
  "revokedAt": null
}

A project is a repository, the settings used to build it, and the environments it deploys to.

Response

// ProjectView
{
  "id": 42,
  "workspaceId": 1,
  "name": "storefront",
  "repoFullName": "acme/storefront",
  "framework": "nextjs",
  "githubInstallationId": 90210,
  "analyticsEnabled": true,
  "environments": ["PRODUCTION", "PREVIEW"],
  "scmProvider": "github",
  "repoCloneUrl": "https://github.com/acme/storefront.git",
  "hasRepoToken": false
}

Configuration and secrets, per project and per environment. Encrypted at rest, and write-only: no route on this platform will read a value back to you.

envKind in the path is PRODUCTION or PREVIEW, matched case-insensitively — production works just as well as PRODUCTION.

Response

// GET → EnvVarKeyView[] — keys only. A value is never returned by any route.
{
  "key": "DATABASE_URL",
  "updatedAt": "2026-07-14T09:12:00Z"
}

A build turns a commit into a deployable artifact. Starting one is exactly what the “deploy” button does.

Response

// BuildView
{
  "id": 1001,
  "projectId": 42,
  "commitSha": "9f2c1ab",
  "branch": "main",
  "envKind": "PRODUCTION",
  "status": "READY",
  "artifactId": 55,
  "createdAt": "2026-07-14T09:12:00Z"
}

// GET /logs → BuildLogsView. droppedLines > 0 means the buffer overflowed and
// the log you are reading is not complete.
{
  "lines": [
    { "id": 1, "level": "INFO", "message": "▲ Next.js 16.0.0", "emittedAt": "2026-07-14T09:12:03Z" },
    { "id": 2, "level": "INFO", "message": "Creating an optimized production build …", "emittedAt": "2026-07-14T09:12:04Z" }
  ],
  "droppedLines": 0
}

A deployment is an artifact that is live somewhere. Promote and rollback move an alias between deployments; neither rebuilds anything, so both are near-instant.

Response

// DeploymentView
{
  "id": 300,
  "projectId": 42,
  "buildId": 1001,
  "artifactId": 55,
  "envKind": "PRODUCTION",
  "status": "READY",
  "immutableUrl": "https://storefront-9f2c1ab.mmoall.app",
  "createdAt": "2026-07-14T09:14:00Z"
}

// promote and rollback → AliasView: where the alias points now.
{
  "host": "storefront.mmoall.app",
  "projectId": 42,
  "envKind": "PRODUCTION",
  "deploymentId": 300,
  "contentHash": "sha256:…",
  "storageKey": "artifacts/55.tar.zst",
  "updatedAt": "2026-07-14T09:15:00Z"
}

Put your own hostname in front of a project. Ownership is proven with a DNS record before we will serve traffic for it.

Response

// CustomDomainView — challengeRecord* is the DNS record you must publish before verifying.
{
  "id": 9,
  "projectId": 42,
  "host": "shop.acme.vn",
  "envKind": "PRODUCTION",
  "status": "PENDING",
  "challengeRecordName": "_mmoall-challenge.shop.acme.vn",
  "challengeRecordValue": "mmoall-verify=8f3c…",
  "verifiedAt": null,
  "createdAt": "2026-07-14T09:12:00Z"
}

Two different questions, answered by two deliberately separate routes: how many requests hit the edge, and how many people came. A request is not a visit, and these numbers are never mixed together.

Response

// ObservabilityView — requests, from the edge.
{
  "requests24h": 128400,
  "errorRate": 0.004,
  "avgLatencyMs": 63,
  "series": [ /* … */ ]
}

// AnalyticsView — people, from the beacon. A request and a page view are
// different questions; these two responses never mix them.
{
  "visitors7d": 4120,
  "pageViews7d": 9880,
  "visitorsChangePct": 12.5,
  "pageViewsChangePct": -3.1,
  "topPages": [ /* … */ ]
}

Rules the edge enforces on your visitors, before a request ever reaches your app. Changes reach the edge within seconds — nothing has to be redeployed.

Custom rules, IP rules and managed rulesets are capped per plan. Going over answers 409 PLAN_LIMIT_EXCEEDED — and the overview route tells you the caps, and your usage against them, before you try.

Response

// GET /waf → WafOverviewView: hosts, policies, rules, IP rules and your plan's
// caps, in one round trip.
{
  "hosts": ["*", "shop.acme.vn"],
  "policies": [
    { "id": 1, "projectId": 42, "host": "*", "enabled": true, "mode": "BLOCK",
      "managedRulesets": ["sqli", "xss"], "updatedAt": "2026-07-14T09:12:00Z" }
  ],
  "rules": [
    { "id": 5, "projectId": 42, "name": "block-admin", "priority": 100, "enabled": true,
      "action": "BLOCK", "hosts": ["*"],
      "conditions": [{ "field": "path", "op": "starts_with", "value": "/wp-admin" }],
      "updatedAt": "2026-07-14T09:12:00Z" }
  ],
  "ipRules": [
    { "id": 3, "projectId": 42, "kind": "DENY", "cidr": "203.0.113.0/24", "hosts": ["*"],
      "note": "scraper", "expiresAt": null, "createdAt": "2026-07-14T09:12:00Z" }
  ],
  "limits": {
    "wafEnabled": true, "maxCustomRules": 20, "maxIpRules": 50,
    "maxManagedRulesets": 3, "usedCustomRules": 1, "usedIpRules": 1
  }
}

// A RATE_LIMIT rule carries a rateLimit budget; no other action does.
"rateLimit": { "requests": 100, "windowSeconds": 60, "burst": 20, "key": "ip" }

The public price lists behind the marketing pages. No key needed: these are the only routes on the API you can call without one.