AI Studio

Use it to accelerate a draft, then review configuration, credentials, generated code, and behavior before deploying. A generated workflow or successful validation does not prove that provider access or business logic is correct. Suggested operational fixes are not automatically applied to a running flow.

Start in the web app

1. Open AI Studio in your workspace.
2. Choose an available tier. Availability and limits depend on your plan and credit balance.
3. Describe the trigger, source, transformations, destination, and failure behavior. Refer to existing flow and connector names when relevant.
4. Review the generated canvas and source. Fill in required provider settings and secrets.
5. Validate, save a draft, and test with representative inputs before deployment.

A useful prompt is:

Build a workflow that receives an order ID, fetches the order from our HTTPS API, rejects missing customer IDs, and writes the normalized result to object storage. Route invalid records to a review destination. Keep credentials in environment secrets.

Ask for an explanation or run investigation when you do not want a new workflow. For example: “Explain why run RUN_ID failed and suggest the smallest configuration change.” Available tools depend on the deployed service. Web research is available only where enabled; source links are returned when research is used.

Discover tiers and credits

All requests use authentication. Reads require flows.read; session creation, messages, attachments, and edits require flows.write.

curl --fail-with-body "$DAGY_API_URL/ai-studio/tiers" \
  -H "Authorization: Bearer $DAGY_TOKEN"

Use returned tiers, default_tier, and credits_balance. Tier data includes the limits applicable to the service. Do not hardcode a model name, plan entitlement, conversation limit, or credit cost from an example.

Sending a message can consume credits even when it does not produce a valid deployable workflow. Inspect the response's credits_used and validation result.

Create a session

curl --fail-with-body "$DAGY_API_URL/ai-studio/sessions" \
  -H "Authorization: Bearer $DAGY_TOKEN" \
  -H 'Content-Type: application/json' \
  --data '{"title":"Order ingestion design","flow_name":"process-orders"}'

The response contains session_id, title, tier, status, messages, canvas_state, generated source fields, attachments, credit usage, and timestamps. Omit tier to use the plan's default.

If an active session is already bound to the supplied flow_name, the API returns it instead of creating another. A creation request can include message, but that initial message is stored only; use the messages endpoint to run an AI turn.

Titles permit up to 120 characters. Messages permit up to 8,000 characters. Use attachments for longer reference material.

Send a message

curl --fail-with-body \
  "$DAGY_API_URL/ai-studio/sessions/$SESSION_ID/messages" \
  -H "Authorization: Bearer $DAGY_TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'X-Idempotency-Key: order-design-turn-1' \
  --data '{
    "message":"Design the order ingestion workflow described in our current requirements.",
    "intent":"build",
    "turn_id":"order-design-turn-1"
  }'

The response includes:

An invalid build or modify result returns 422 with this workflow-oriented response and workflow_errors. It is not the usual {"detail":...} API error. Display those errors and request a correction; do not deploy a missing or invalid graph.

Use a stable turn_id for retries of the same turn. The synchronous endpoint also accepts X-Idempotency-Key and rejects detected duplicates with 409. A completed turn returns 409 if resubmitted. After an uncertain timeout, fetch the session and inspect its messages before retrying; this is not a general exactly-once guarantee for generation or billing.

Stream a response

curl --no-buffer --fail-with-body \
  "$DAGY_API_URL/ai-studio/sessions/$SESSION_ID/messages/stream" \
  -H "Authorization: Bearer $DAGY_TOKEN" \
  -H 'Content-Type: application/json' \
  --data '{"message":"Explain this workflow.","intent":"advisory","turn_id":"review-1"}'

The response is text/event-stream. Some Dagy environments provide a separate base URL for streaming; use that URL for this request when supplied by your administrator. A normal API gateway can time out or buffer long responses, so confirm streaming support before implementing this client.

Use a client that supports streaming POST requests with authentication headers, such as a streaming fetch client. Browser EventSource alone cannot send this request shape.

Example frame:

event: token
data: {"delta":"The workflow begins by receiving an order ID."}

Once streaming begins, errors may arrive as SSE events even when the HTTP response was 200. An invalid workflow can produce an error followed by done; inspect workflow_errors in the final event instead of treating done as unconditional success. If the connection closes early, reload the session before retrying.

Attach requirements or sample data

Supported attachment types are PDF, Word (.docx), PowerPoint (.pptx), CSV, plain text/Markdown, JSON, and YAML. Each file must be nonempty and at most 25 MiB (26,214,400 bytes). Attachment counts depend on the selected tier.

1. Initiate an upload:

POST /ai-studio/sessions/SESSION_ID/attachments/initiate
Authorization: Bearer YOUR_DAGY_TOKEN
Content-Type: application/json

{"filename":"requirements.md","file_size":1234,"content_type":"text/plain"}

2. Read upload_url, upload_method, upload_headers, attachment_id, and s3_key from the response. s3_key is an opaque upload handle; preserve it exactly. Upload the actual bytes to the returned URL using the returned method and headers. Do not send your Dagy bearer token to that URL. Upload URLs expire after one hour.
3. Complete the upload:

POST /ai-studio/sessions/SESSION_ID/attachments/complete
Authorization: Bearer YOUR_DAGY_TOKEN
Content-Type: application/json

{
  "attachment_id":"RETURNED_ATTACHMENT_ID",
  "filename":"requirements.md",
  "s3_key":"RETURNED_UPLOAD_HANDLE",
  "content_type":"text/plain"
}

4. Inspect attachment.parse_status and parse_error. An HTTP success does not guarantee that parsing succeeded. Correct or replace a failed attachment before asking the assistant to rely on it.
5. Send a message explaining how the attachment should inform the workflow.

Remove a session attachment with DELETE /ai-studio/sessions/{id}/attachments/{attachment_id}. Submit only reference material you are authorized to use, and keep credentials in your secret store rather than in prompts or sample files.

Manage sessions and drafts

Lists accept active, draft, and archived, including comma-separated combinations. Default status is active; list limits are clamped to 1–100. The list is scoped to the current user; individual session and flow lookups are workspace-scoped. Do not assume conversations are private from other authorized members of the workspace.

Canvas updates must be nonempty JSON objects and cannot exceed 200,000 serialized bytes. Session drafts and generated source are not production deployments; use the normal review, test, and deployment workflow.

Review generated actions

Generated python_function, shell_command, and docker_container nodes can require explicit confirmation. Inspect requires_confirmation and the generated node types before proceeding. Code validation applies restrictions to AI-authored code but does not replace code review or your execution security requirements.

Verify target URLs, data destinations, dependencies, provider permissions, limits, and error branches. Review sample inputs and expected outputs with the same care as hand-written workflows.

Troubleshoot

Legacy /ui/ai-studio/generate and /ui/ai-studio/generate-and-save routes are retired. Integrations should use the session APIs described here.