Build with MUNKY.
Connect your software’s events, give MUNKY actions it can perform, and check the result before calling work complete.
Account verification, keys, event ingestion and capability registration have live test evidence. Complete product account onboarding, general app control and model qualification remain in development.
Create a development key.
Start in the developer console.
02 ↗Read the full guide.
Identity, execution, decisions and verification.
The API connects to your backend. For desktop work, embed the MUNKY runtime and supply the app’s permissions and supported action adapters. A working API key does not give access to someone’s computer.
From account to first request.
Create your developer account.
Open the MUNKY developer console, verify your email and name your project.
Create a development key.
Open Keys, choose development and save the key in your server’s secret store. It is shown once.
Check the connection.
Run the request below from your server or terminal. Confirm the project and environment before creating a test tenant.
Connect one customer workspace.
Follow the full guide to map a tenant and principal, send a projected event and declare a capability. An event is an observation; it does not itself authorize an action.
Use Node 24 or later for the SDK examples. The local runtime has additional toolchain requirements described in its guide.
Keep keys on your server.
Send your project key in Authorization: Bearer. Each key belongs to one project and one environment. Your software keeps its existing user login and maps each customer workspace to a separate tenant.
Never place a project key in browser JavaScript or a desktop installer. Register each desktop runtime through your trusted backend and give it its own scoped credential. A console session, a project key and a device credential serve different purposes.
To replace a key, create another in the same environment, update your server, test it, then revoke the old key in the console. A revoked key is rejected. Human approvals additionally require a registered signing key and an exact principal decision.
MUNKY-hosted end-user account, seat and company-policy onboarding is not yet complete in the public API. Do not integrate against historical /product/v1/* routes.
Check your connection.
The working development origin is https://munkyapi-production.up.railway.app. The intended custom domain is api.munky.sh; its cutover remains unfinished. Use the working origin consistently for the console, API and downloads.
# Supply MUNKY_API_KEY from your private environment.
export MUNKY_API_URL="https://munkyapi-production.up.railway.app"
curl --fail-with-body "$MUNKY_API_URL/v1/whoami" \
-H "Authorization: Bearer $MUNKY_API_KEY"npm install https://munkyapi-production.up.railway.app/sdk/munky-sdk-0.5.0.tgzKeep the resolved package integrity in your lockfile. Continue with the SDK integration guide; it includes tenant creation and event projection.
One step at a time.Start with one request.
Confirm your project and environment.
Then connect one test customer workspace.
Read the result, not just the status code.
A successful GET /v1/whoami returns these fields. Their values come from your actual project and credential.
| Field | Type | Meaning |
|---|---|---|
| projectId | string | The project this key belongs to. |
| environment | string | development, staging or production. |
| credentialId | string | Credential identifier, not its secret. |
| scopes | string[] | Operations granted to this key. |
| surfaces | object | Boolean access indicators derived from scopes, not proof of configured providers or product readiness. |
For event batches, inspect every item: HTTP 200 does not mean all events were accepted. Unmapped events need confirmed meaning. For actions, performed is a report; only independent verification establishes a successful receipt.
Recover without repeating the effect.
API errors include an error code; some also provide message or validation details. Do not depend on every error having identical fields.
| Status | What to do |
|---|---|
| 401 | Check the credential and whether it was revoked. Do not keep retrying the same key. |
| 403 | Check project, environment, tenant, scopes and principal authority. |
| 409 | Read current state. A conflicting or already-consumed decision cannot be replaced by a blind retry. |
| 413 / 422 | Reduce the payload or correct the fields described by the route schema. |
| 429 | Honor the Retry-After header. |
| 5xx / lost response | Check whether the effect happened before resubmitting. Preserve supported idempotency keys and use bounded retries. |
Do not automatically retry phone verification sends or code submissions. SDK decision retries retain the same serialized request. Never treat a changed quote, expired approval or ambiguous purchase as a fresh attempt.
Know the operating boundaries.
There is no published universal throughput allowance or service-level commitment yet. Request limits and provider allowances depend on deployment configuration; handle explicit limits rather than assuming unlimited usage.
The server’s default JSON body cap is 2 MiB and can be configured. Event-list requests accept a limit from 1 to 1,000. Phone codes expire after ten minutes and allow five verification attempts; delivery has additional abuse limits. These are implementation limits, not a pricing plan.
Read GET /v1/usage for available project usage data. Published API/runtime packages do not establish that every application or task is supported.
Every public route.
Methods, scopes, schemas and request examples.
Run the engine locally.
Launch protocol, dependencies and model boundaries.
Download the machine-readable route contract · Documentation checksums