You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Job status transitions follow: `queued` → `processing` → `completed`or `failed`. The `output` field is only present when status is `completed`.
131
+
Execution status transitions follow: `queued` → `running` → `completed`, `failed`, `cancelled`, or `paused`. The `data.output` field is populated for completed executions when `includeOutput=true`.
133
132
</Callout>
134
133
135
134
## Response Format
136
135
137
-
Successful responses include an `output` object with your workflow results and a `limits` object with your current rate limit and usage status:
136
+
Successful v2 responses wrap the execution resource in `data`:
The API uses standard HTTP status codes. Error responses include a human-readable`error` message:
153
+
The API uses standard HTTP status codes. v2 errors include a stable code and human-readable message:
173
154
174
155
```json
175
156
{
176
-
"error": "Workflow not found"
157
+
"error": {
158
+
"code": "NOT_FOUND",
159
+
"message": "Workflow not found"
160
+
}
177
161
}
178
162
```
179
163
@@ -191,7 +175,7 @@ The API uses standard HTTP status codes. Error responses include a human-readabl
191
175
192
176
## Rate Limits
193
177
194
-
Rate limits depend on your subscription plan and apply separately to synchronous and asynchronous executions. Every execution response includes a `limits` object showing your current rate limit status.
178
+
Rate limits depend on your subscription plan and apply separately to synchronous and asynchronous executions.
195
179
196
180
When rate limited, the API returns a `429` response with a `Retry-After` header indicating how many seconds to wait before retrying.
-`error` (dict, optional): Structured failure details with `code`, `message`, and optional `details`
143
+
144
+
##### get_job_status()
145
+
146
+
Get the status of a job created through the legacy async execution endpoint. New integrations should use `get_workflow_execution()` with the execution ID instead.
147
+
148
+
```python
149
+
status = client.get_job_status("legacy-job-id")
150
+
```
139
151
140
152
##### execute_with_retry()
141
153
@@ -270,9 +282,8 @@ class WorkflowExecutionResult:
270
282
@dataclass
271
283
classAsyncExecutionResult:
272
284
success: bool
273
-
job_id: str
285
+
execution_id: str
274
286
status_url: str
275
-
execution_id: Optional[str] =None
276
287
message: str=""
277
288
async_execution: bool=True
278
289
```
@@ -494,22 +505,26 @@ def execute_async():
494
505
)
495
506
496
507
# Check if result is an async execution
497
-
ifhasattr(result, 'job_id'):
498
-
print(f"Job ID: {result.job_id}")
508
+
ifhasattr(result, 'async_execution') and result.async_execution:
@@ -765,9 +780,9 @@ import { FAQ } from '@/components/ui/faq'
765
780
766
781
<FAQitems={[
767
782
{ question: "Do I need to deploy a workflow before I can execute it via the SDK?", answer: "Yes. Workflows must be deployed before they can be executed through the SDK. You can use the validate_workflow() method to check whether a workflow is deployed and ready. If it returns False, deploy the workflow from the Sim UI first and create or select an API key during deployment." },
768
-
{ question: "What is the difference between sync and async execution?", answer: "Sync execution (the default) blocks until the workflow completes and returns the full result. Async execution (async_execution=True) returns immediately with a job ID and status URL that you can poll using get_job_status(). Use async mode for long-running workflows to avoid request timeouts. Async job statuses include queued, processing, completed, failed, and cancelled." },
783
+
{ question: "What is the difference between sync and async execution?", answer: "Sync execution (the default) blocks until the workflow completes and returns the full result. Async execution (async_execution=True) returns immediately with an execution ID and status URL that you can poll using get_workflow_execution(). Use async mode for long-running workflows to avoid request timeouts. Execution statuses include queued, pending, running, paused, completed, failed, and cancelled." },
769
784
{ question: "How does the SDK handle rate limiting?", answer: "The SDK provides built-in rate limiting support through the execute_with_retry() method. It uses exponential backoff (1s, 2s, 4s, 8s...) with 25% jitter to avoid thundering herd problems. If the API returns a retry-after header, that value is used instead. You can configure max_retries, initial_delay, max_delay, and backoff_multiplier. Use get_rate_limit_info() to check your current rate limit status." },
770
785
{ question: "Can I use the Python SDK as a context manager?", answer: "Yes. The SimStudioClient supports Python's context manager protocol. Use it with the 'with' statement to automatically close the underlying HTTP session when you are done, which is especially useful for scripts that create and discard client instances." },
771
786
{ question: "How do I handle different types of errors from the SDK?", answer: "The SDK raises SimStudioError with a code property for API-specific errors. Common error codes are UNAUTHORIZED (invalid API key), TIMEOUT (request timed out), RATE_LIMIT_EXCEEDED (too many requests), USAGE_LIMIT_EXCEEDED (billing limit reached), and EXECUTION_ERROR (workflow failed). Use the error code to implement targeted error handling and recovery logic." },
772
787
{ question: "How do I monitor my API usage and remaining quota?", answer: "Use the get_usage_limits() method to check your current usage. It returns sync and async rate limit details (limit, remaining, reset time, whether you are currently limited), plus your current period cost, usage limit, and plan tier. This lets you monitor consumption and alert before hitting limits." },
0 commit comments