Your first request.

Send the model context and named questions. You define the response format.

{
  "state": "Card payments are not working. Payment on delivery is available.",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this issue?",
      "criteria": {
        "engineering": "Website and integration failures",
        "logistics": "Delivery questions"
      }
    }
  }
}

Save this object as request.json. Set your Shvydko service address in SHVYDKO_BASE_URL without a trailing slash, and your key in SHVYDKO_API_KEY.

curl "$SHVYDKO_BASE_URL/v1/systemone" \
  -H "Authorization: Bearer $SHVYDKO_API_KEY" \
  -H "Content-Type: application/json" \
  --data @request.json

One context. Several questions.

state contains the text or JSON data the model should assess. In questions , each question has its own name, which identifies its answer in the result.

• Include the rules and facts needed for the decision, without unnecessary noise.
• Specify what should happen when information is missing. For example, add a matching option to Choice.
• Calculate dates and exact amounts in code, then pass the resulting facts to the model.

Three response types

{
  "type": "choice",
  "instructions": "Which team should handle this request? Choose based on the main cause of the problem.",
  "criteria": {
    "engineering": "Engineering: website or integration failure",
    "finance": "Finance: invoices and refunds of charged payments",
    "logistics": "Logistics: shipping and delivery"
  }
}

{
  "type": "score",
  "instructions": "Assess how the described issue affects placing orders.",
  "criteria": [
    "Does not prevent placing orders",
    "Makes ordering harder for one customer",
    "Blocks one payment method for many customers",
    "Blocks every ordering method for all customers"
  ]
}

{
  "type": "noul",
  "instructions": "Under the stated policy, this request requires urgent human review."
}

API reference

Send Authorization: Bearer YOUR_API_KEY and Content-Type: application/json. This request uses the model configured for the service. Never expose a secret key in client-side code.

import json
import os
import urllib.request

with open("request.json", encoding="utf-8") as f:
    body = json.load(f)

request = urllib.request.Request(
    os.environ["SHVYDKO_BASE_URL"] + "/v1/systemone",
    data=json.dumps(body).encode("utf-8"),
    headers={
        "Authorization": "Bearer " + os.environ["SHVYDKO_API_KEY"],
        "Content-Type": "application/json",
        "User-Agent": "ShvydkoClient/1.0",
    },
)
with urllib.request.urlopen(request) as response:
    result = json.load(response)
print(result)

Probability for your application logic.

Probabilities help separate automatic processing from review. Choose a threshold on your own labeled sample, taking the cost of errors into account.

For critical operations, final rules and authorization to act must remain in your system. The model provides an assessment; the request itself does not perform the business actions it describes.

Share a request

In the Playground, select Share and choose who can access the request before creating the link. By default, only signed-in members of your organization can access the context and questions.

Anyone with the link makes the request accessible without signing in. This option is available if your organization allows public links. Check that the data can be shared before publishing. The author or an administrator can delete the link under Shared requests.

Errors and limits

Current model token limits are returned by GET /v1/models with your Bearer API key, in the fields context.max_state and context.max_branch. The first field limits tokens in the shared context; the second limits the context together with one question, its criteria and system tokens. These are not character counts or the sum of all questions. If context.strict is true, requests exceeding the limit are rejected.

The number of questions and the JSON body size in bytes are separate API request limits. They appear above the Playground editor alongside the model limits. In early access, the workspace's daily request limit is also shown there; it resets at 00:00 UTC. Runs that fail after being sent to the model also count toward this limit. Access also depends on the service-wide daily limit. Pricing and payment availability depend on the service configuration.