Logic runs your decision models against JSON input. Use its API to evaluate a version, manage environments and deployments, and execute a deployed decision from your application.

Core concepts

• Decision: a model that transforms input facts into a result. Author it in the Logic app.
• Version: a saved snapshot, shown as v1, v2, and so on. API requests use the numeric version. Version 0 is the editable working copy; use a saved version for reproducible runs.
• Environment: a workspace resource such as Test or Production. These names are yours to choose and are separate from the Neobits test and production API hosts.
• Deployment: connects a decision version to an environment. Creating one through REST also creates immediate 100% traffic routing.
• Evaluation: runs the requested version without deployment routing and returns its result and available trace.
• Execution: runs the version selected by an environment's deployment routing and records the outcome.

Authentication and workspace access

Obtain an access token through Core authentication. Configure your API client for Logic and grant the scopes needed for its operations. Send Authorization: Bearer <access_token> and X-Workspace-Id on every request. The token must be valid for the target API and tenant, and its principal must have access to the workspace. End-user tokens are authorized through workspace policies.

The test API base URL is https://api.test.neobits.no; production uses https://api.prod.neobits.no. Logic paths start with /logic. JSON field names are camelCase.

A missing or malformed workspace header returns 400. Authentication failures return 401; insufficient access returns 403. Environment and deployment reads are limited to the active workspace.

Evaluate, deploy, and execute

Start with a standalone decision and a saved version in the Logic app. Copy its decision ID from the decision details and use the numeric saved version from its version history. Use your active workspace ID for WORKSPACE_ID. The following example assumes a decision that accepts an age fact and returns an eligible result; use the input required by your own decision.

API_URL='https://api.test.neobits.no'
ACCESS_TOKEN='<your-access-token>'
WORKSPACE_ID='<your-workspace-uuid>'
DECISION_ID='<your-decision-uuid>'
VERSION=1

1. Create an environment

Only the name is required. Omitting the color selects a random supported theme color. Copy the returned id into ENVIRONMENT_ID.

curl --request POST "$API_URL/logic/environments" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "X-Workspace-Id: $WORKSPACE_ID" \
  --header 'Content-Type: application/json' \
  --data '{"name":"Test","description":"Integration testing","color":"#2563eb"}'

Example 201 response:

{
  "id": "019991b1-0000-7000-8000-000000000002",
  "workspaceId": "019991b1-0000-7000-8000-000000000001",
  "name": "Test",
  "description": "Integration testing",
  "color": "#2563eb",
  "createdAt": "2026-09-30T10:00:00.000Z",
  "updatedAt": "2026-09-30T10:00:00.000Z"
}

ENVIRONMENT_ID='<id-from-the-create-environment-response>'

2. Evaluate the saved version

Evaluation requires no deployment. The REST endpoint has no environment parameter, so it does not resolve environment configuration variables. Evaluations run the decision's logic and can call external integrations; they are not side-effect-free dry runs.

curl --request POST "$API_URL/logic/decisions/$DECISION_ID/evaluations" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "X-Workspace-Id: $WORKSPACE_ID" \
  --header 'Content-Type: application/json' \
  --data "{\"version\":$VERSION,\"fact\":{\"age\":25}}"

The 201 response includes id, status, result, performance, and trace. A successful result might be {"eligible":true}. Trace entries depend on the model's nodes; configuration secrets are redacted.

3. Deploy the version

Creating a deployment immediately directs 100% of traffic for this decision/environment pair to the selected version. Supply the caller attribution in deployedBy; it is not inferred from the token. Copy the returned id into DEPLOYMENT_ID.

curl --request POST "$API_URL/logic/deployments" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "X-Workspace-Id: $WORKSPACE_ID" \
  --header 'Content-Type: application/json' \
  --data "{\"decisionId\":\"$DECISION_ID\",\"version\":$VERSION,\"environmentId\":\"$ENVIRONMENT_ID\",\"name\":\"Eligibility v1\",\"message\":\"Initial deployment\",\"deployedBy\":\"Integration service\"}"

Both the environment and decision snapshot must exist in the active workspace. Deploy sub-decisions through their parent. A deployment version of null or 0 selects the working copy; the response normalizes null to 0. The REST API does not accept rollout percentages or scheduling settings.

DEPLOYMENT_ID='<id-from-the-create-deployment-response>'

4. Execute the deployed decision

Execution resolves configuration variables for the environment and follows its deployment routing.

curl --request POST "$API_URL/logic/$ENVIRONMENT_ID/decisions/$DECISION_ID/executions" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "X-Workspace-Id: $WORKSPACE_ID" \
  --header 'Content-Type: application/json' \
  --data '{"fact":{"age":25}}'

Example 201 response:

{
  "id": "019991b1-0000-7000-8000-000000000005",
  "decisionId": "019991b1-0000-7000-8000-000000000003",
  "status": "COMPLETED",
  "result": {"eligible": true},
  "performance": "1.2ms",
  "createdAt": "2026-09-30T10:00:00.000Z",
  "updatedAt": "2026-09-30T10:00:00.000Z"
}

List and paginate resources

Environment and deployment lists accept size (default 50, maximum 5,000) and either before or after. Results are ordered by ascending ID. The cursors are exclusive; use page.after for the next page and page.before for the preceding page. Responses use { data, page }, with page.size equal to the returned count and page.total equal to the workspace total.

curl "$API_URL/logic/deployments?size=50" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "X-Workspace-Id: $WORKSPACE_ID"

AFTER='<page.after-from-the-previous-response>'
curl "$API_URL/logic/deployments?size=50&after=$AFTER" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "X-Workspace-Id: $WORKSPACE_ID"

A non-null cursor does not guarantee another page exists. An empty page contains data: [], size: 0, and null cursors, while total still reports the workspace total. These lists do not accept decision/environment filters or custom sorting. Use GET /logic/environments/{id} or GET /logic/deployments/{id} to retrieve an individual resource.

Update and delete resources

PATCH requests require at least one supported field. Omitted fields stay unchanged. Use null or an empty string to clear an environment description or a deployment message. Unknown fields are rejected.

curl --request PATCH "$API_URL/logic/environments/$ENVIRONMENT_ID" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "X-Workspace-Id: $WORKSPACE_ID" \
  --header 'Content-Type: application/json' \
  --data '{"description":"Shared integration environment"}'

curl --request PATCH "$API_URL/logic/deployments/$DEPLOYMENT_ID" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "X-Workspace-Id: $WORKSPACE_ID" \
  --header 'Content-Type: application/json' \
  --data '{"message":"Verified by integration tests"}'

Deployment PATCH also accepts decisionId, version, environmentId, name, and deployedBy. It validates the resulting references, but updates only the deployment record; existing routing is not recreated or changed. Create a new deployment when you want to activate another version with immediate full-traffic routing.

Deleting an environment also deletes its deployments and routings. Deleting a deployment removes its routings and can change the version that receives future traffic. Both deletions return 409 Conflict when linked execution history prevents removal. The deployment executed in this walkthrough therefore cannot be deleted through these calls while that history remains.

For a disposable resource without execution history:

curl --request DELETE "$API_URL/logic/deployments/$DEPLOYMENT_ID" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "X-Workspace-Id: $WORKSPACE_ID"

curl --request DELETE "$API_URL/logic/environments/$ENVIRONMENT_ID" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "X-Workspace-Id: $WORKSPACE_ID"

Successful deletion returns 204 with no body. Repeating the deletion for an absent resource in the active workspace also returns 204.

Handle HTTP and decision failures

Check both the HTTP status and the result's status. A 201 response can contain status: "FAILED" and a result.error message when a node fails. An execution may include a diagnostic trace for that failure; successful executions normally omit it. Evaluations return their available trace in the trace field.

For example, a failed evaluation can return:

{
  "id": "019991b1-0000-7000-8000-000000000006",
  "status": "FAILED",
  "result": {"error": "The external integration failed."},
  "performance": "4.2ms",
  "trace": null
}

A hard engine failure can instead produce a non-2xx response. Do not assume every failed evaluation was persisted. Missing deployments, routing, or decision versions can return 404. For HTTP errors, use the shared error response format and the status codes listed on each operation.