Skip to main content
Use these patterns to handle failures gracefully - checking 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 check success before using data:

Uncaught Exceptions

Uncaught exceptions in run 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 returns success: false with an error message. No SDK-side option is needed.
This applies to all transacting methods: signAndSend, swap.execute, polymarket.marketOrder, and polymarket.redeemPositions.

General Error Patterns

Tips

  • Always check success before using data
  • Log errors with error: true / error=True so 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: true so they appear in the UI