Quickstart

POST /onboarding/signup is public and IP rate-limited — it creates a brand-new organization plus its first admin account, and hands back both a session token and an API key in one response.

curl -X POST https://api.flowawsome.com/onboarding/signup \
  -H "Content-Type: application/json" \
  -d '{
    "companyName": "Acme Inc",
    "slug": "acme",
    "adminEmail": "admin@acme.com",
    "adminDisplayName": "Acme Admin",
    "adminPassword": "correct-horse-battery-staple"
  }'

The response from step 1 gives you two different credentials for two different callers — use whichever matches who's making the next call:

• accessToken — a session JWT for the admin user you just created. Send it as Authorization: Bearer <token> from your backend or backend-for-frontend. The API does not send CORS headers, so a browser cannot call it directly.
• apiKey.rawToken — a secret key for your whole organization, with no expiry: it works for every app and service, including adding and deactivating members through HR sync. Send it as X-Api-Key: <token> from server-side code only. It's shown once, in this response. For a system that only needs one service, issue a narrower key via POST /access-control/api-keys with appId, serviceId, and expiresAt, and keep this one for administration.

This is the call an external system (ERP, an internal tool) makes to kick off an approval — the resolution engine picks the workflow definition and approver chain for you.

curl -X POST https://api.flowawsome.com/services/$SERVICE_ID/workflow-instances \
  -H "X-Api-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "resourceType": "purchase_order",
    "resourceId": "po-10231",
    "initiatorUserId": "'$USER_ID'",
    "idempotencyKey": "po-10231-submit-1"
  }'

See the Workflow API in the Reference for step actions (approve/reject). Reading an instance's status takes a user's bearer token (the requester, an approver, or an admin); a system that holds only an API key learns about status changes through webhooks.

@flowaws/node-sdk is optional — everything above is reproducible with plain REST — but it does two things locally, without calling back into the API: verifying a webhook signature, and verifying an access token.

npm install @flowaws/node-sdk

• Building your own login screen instead of the hosted admin console? The Auth endpoints under the Identity API are a stable public contract you can call directly — see Identity API.
• Registering a webhook endpoint to receive workflow, member and access events — see POST /workflows/webhook-endpoints in the Workflow API.
• Granting a department or job title access to a service instead of one API key at a time — see the Access Control API.