Endpoint
Description
Submits a new task to Shannon for execution. The task is queued immediately and processed asynchronously by the Temporal workflow engine.Authentication
Required: Yes Include API key in header:Request
Headers
| Header | Required | Description | Example |
|---|---|---|---|
X-API-Key | Yes | Authentication key | sk_test_123456 |
Content-Type | Yes | Must be application/json | application/json |
Idempotency-Key | No | Unique key for idempotency | 550e8400-e29b-41d4-a716-446655440000 |
traceparent | No | W3C trace context | 00-4bf92f... |
Body Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
query | string | Yes | Natural language task description |
session_id | string | No | Session identifier for multi-turn conversations |
context | object | No | Additional context data as key-value pairs |
mode | string | No | Workflow routing: simple, standard, complex, or supervisor |
model_tier | string | No | Preferred tier: small, medium, or large |
model_override | string | No | Specific model name (canonical; e.g., gpt-5, claude-sonnet-4-5-20250929) |
provider_override | string | No | Force provider (e.g., openai, anthropic, google) |
Request Body Schema
Example 1: General AI-powered executionParameter Conflicts to Avoid:
- Don’t use both
templateandtemplate_name(they’re aliases - usetemplateonly) - Don’t combine
disable_ai: truewith model controls - Gateway returns 400 error when conflicts detected:disable_ai: true+model_tier→ 400disable_ai: true+model_override→ 400disable_ai: true+provider_override→ 400
- Top-level parameters override context equivalents:
- Top-level
model_tieroverridescontext.model_tier - Top-level
model_overrideoverridescontext.model_override - Top-level
provider_overrideoverridescontext.provider_override
- Top-level
Context Parameters
Recognized keys incontext:
role— role preset (e.g.,analysis,research,writer)system_prompt— overrides role prompt; supports${var}fromprompt_paramsprompt_params— arbitrary parameters for prompts/tools/adaptersmodel_tier— fallback when top‑level not provided
Response
Success Response
Status:200 OK
Headers:
X-Workflow-ID: Temporal workflow identifierX-Session-ID: Session identifier (auto-generated if not provided)
Response Fields
| Field | Type | Description |
|---|---|---|
task_id | string | Unique task identifier (also workflow ID) |
status | string | Submission status (e.g., STATUS_CODE_OK) |
message | string | Optional status message |
created_at | timestamp | Task creation time (ISO 8601) |
Examples
Basic Task Submission
Task with Session ID (Multi-Turn)
Task with Context
Force Tier (Top‑Level)
Template‑Only Execution
Supervisor Mode
With Idempotency
With Distributed Tracing
Error Responses
400 Bad Request
Missing Query:401 Unauthorized
Missing API Key:429 Too Many Requests
X-RateLimit-Limit: 100X-RateLimit-Remaining: 0X-RateLimit-Reset: 1609459200Retry-After: 60
500 Internal Server Error
Code Examples
Python with httpx
Python with requests
JavaScript/Node.js
cURL with Idempotency
Go
Implementation Details
Workflow Creation
When you submit a task:- Gateway receives request → Validates authentication, rate limits
- Generates session ID → If not provided, auto-generates UUID
- Calls Orchestrator gRPC →
SubmitTask(metadata, query, context) - Orchestrator starts Temporal workflow → Durable execution
- Response returned → Task ID, initial status
- Task executes asynchronously → Independent of HTTP connection
Idempotency Behavior
Idempotency keys allow safe retries of task submissions without creating duplicate tasks. How it works:-
First request with an
Idempotency-Key:- Shannon creates the task
- Caches the response in Redis with 24-hour TTL
- Returns task ID and status
-
Duplicate requests (same
Idempotency-Key):- Shannon detects the cached response
- Returns the same task ID without creating a new task
- Response is identical to the first request
-
After 24 hours:
- Cache expires
- New request with same key creates a new task
- Storage: Redis
- TTL: 24 hours (86400 seconds)
- Key format:
idempotency:<16-char-hash>(SHA-256 of the idempotency key plus user ID, path, and request body) - Scope: Per authenticated user (user ID is part of the hash; when auth is disabled the hash is based on the header, path, and body)
- Cached responses: Only 2xx responses are stored; cached hits include
X-Idempotency-Cached: trueandX-Idempotency-Key: <your-key>
- Network retry logic (avoid duplicate tasks on timeout)
- Webhook deliveries (handle duplicate webhook calls)
- Critical operations (payments, data writes)
- Background job queues (prevent duplicate scheduling)
Session Management
- No session_id: Auto-generates UUID, fresh context
- With session_id: Loads previous conversation history from Redis
- Session persistence: 30 days default TTL
- Multi-turn conversations: All tasks with same
session_idshare context
Context Object
Thecontext object is stored as metadata and passed to:
- Agent execution environment
- Tool invocations (can access via
ctx.get("key")) - Session memory (for reference in future turns)
- User preferences:
{"language": "spanish", "format": "markdown"} - Business context:
{"company_id": "acme", "department": "sales"} - Constraints:
{"max_length": 500, "tone": "formal"}
Best Practices
1. Always Use Idempotency Keys for Critical Tasks
2. Use Sessions for Conversations
3. Provide Rich Context
4. Handle Errors Gracefully
5. Store Task IDs for Tracking
Submit + Stream in One Call
Need real-time updates? Use
POST /api/v1/tasks/stream instead to submit a task and get a stream URL in one call. Perfect for frontend applications that need immediate progress updates.See Unified Submit + Stream for examples.