success before using data, logging errors for visibility in the UI, and matching specific error codes when you need different recovery logic per failure type.
Response Structure
All SDK methods return response objects:Checking Results
Always checksuccess before using data:
Uncaught Exceptions
Uncaught exceptions inrun or unwind are caught by the SDK. The execution is marked as failed and the error is logged. You don’t need to wrap SDK method calls in try/catch blocks unless you need to handle for a specific error.
Correlating Transport Failures
When an engine request fails at the HTTP, network, timeout, or run-deadline boundary, the SDK error includes the request ID sent to Circuit. The rendered error message also ends with(requestId=...), so the ID survives in normal agent logs. In custom error handling, read error.request_id in Python or error.requestId in TypeScript and include it when reporting the failure; it is the lookup key Circuit operators use to find the matching service logs.
When to Use Try/Catch
Only use try/catch for your own logic that might throw (parsing, calculations with external data, custom recovery). Don’t use it for SDK method calls - just check.success instead.
Swap Error Codes
Swap methods (agent.swap.quote(), agent.swap.execute()) return typed error codes in the error field:
Hyperliquid Error Codes
Hyperliquid methods (agent.platforms.hyperliquid.*) return error messages in the error field. See Hyperliquid: Common Errors for the full table.
Polymarket Error Codes
Polymarket methods (agent.platforms.polymarket.*) return typed error codes:
Transaction Reverts
The server automatically waits for onchain confirmation after broadcasting a transaction. If the transaction was mined but reverted onchain, the response returnssuccess: false with an error message. No SDK-side option is needed.
signAndSend, swap.execute, polymarket.marketOrder, and polymarket.redeemPositions.
General Error Patterns
Tips
- Always check
successbefore usingdata - Log errors with
error: true/error=Trueso they show up in the UI - Return early on errors instead of continuing
- Validate inputs before making SDK calls
- Match against specific error codes when you need different handling per failure type
See Also
- Troubleshooting - Common issues and solutions for CLI, SDK, and platform-specific problems
- Logging - Log errors with
error: trueso they appear in the UI