Skip to main content

Disconnect

Disconnects from the Calendly API by releasing the client connection and cleaning up resources.

Common Properties​

  • Name - The custom name of the node.
  • Color - The custom color of the node.
  • Delay Before (sec) - Waits in seconds before executing the node.
  • Delay After (sec) - Waits in seconds after executing node.
  • Continue On Error - Automation will continue regardless of any error. The default value is false.
info

If the ContinueOnError property is true, no error is caught when the project is executed, even if a Catch node is used.

Inputs​

  • Client Id - The unique client identifier returned by the Connect node. This identifies which connection to disconnect.

How It Works​

The Disconnect node safely terminates a Calendly API connection that was established with a Connect node. It removes the stored authentication credentials from memory and releases associated resources.

When executed, the node:

  1. Receives the Client ID from the Connect node
  2. Locates the associated connection in the internal client registry
  3. Removes the connection and cleans up authentication data
  4. Releases memory resources

Requirements​

  • A valid Client ID from a previously executed Connect node
  • The Client ID must correspond to an active connection

Error Handling​

The node will return specific errors in the following cases:

ErrInvalidArg

  • The Client ID is empty or missing
  • Solution: Ensure the Client ID from Connect node is properly passed

ErrInternal

  • Failed to retrieve or delete the client connection
  • The Client ID doesn't match any active connection
  • Solution: Verify the Connect node executed successfully and the Client ID is valid

Usage Example​

Basic Connect-Disconnect Pattern​

[Start]
  -> [Calendly Connect] (outputs: client_id)
  -> [Get Me] (uses: client_id)
  -> [Calendly Disconnect] (uses: client_id)
  -> [End]

Multiple Operations Before Disconnect​

[Start]
  -> [Calendly Connect] (outputs: client_id)
  -> [Get Me]
  -> [List Webhook Subscriptions]
  -> [Add Webhook Subscription]
  -> [Calendly Disconnect]
  -> [End]

Error Handling with Try-Catch​

[Start]
  -> [Try]
    -> [Calendly Connect]
    -> [Get Me]
    -> [Calendly Disconnect]
  -> [Catch]
    -> [Log Error]
    -> [Calendly Disconnect] (ensure cleanup even on error)
  -> [End]

Usage Notes​

  • The Disconnect node should be the last Calendly operation in your flow
  • Always disconnect to prevent memory leaks in long-running automations
  • The Client ID is required to identify which connection to close
  • If a flow ends without calling Disconnect, connections are automatically cleaned up
  • Disconnecting an already-closed connection will result in an error
  • The node doesn't make any API calls to Calendly - it only cleans up local resources

Best Practices​

  • Always pair Connect with Disconnect for proper resource management
  • Place Disconnect in both success and error paths to ensure cleanup
  • Use a Try-Finally pattern to guarantee disconnection even on errors
  • In parallel flows, ensure all operations complete before disconnecting
  • Don't reuse a Client ID after calling Disconnect
  • For long-running automations, disconnect between logical operation groups

Resource Management​

The Disconnect node is important for:

  • Memory efficiency - Prevents credential accumulation in memory
  • Security - Removes sensitive authentication data when no longer needed
  • Clean architecture - Explicitly manages connection lifecycle
  • Debugging - Makes connection scope clear in flow design

When to Disconnect​

Always Disconnect:

  • At the end of a complete Calendly workflow
  • Before long delays in the flow
  • After batch processing multiple Calendly operations
  • In error handlers to ensure cleanup

Optional Disconnect:

  • In very short, simple flows (auto-cleanup occurs on flow end)
  • When immediately reconnecting with different credentials

Automatic Cleanup​

Even without calling Disconnect:

  • Connections are automatically cleaned up when the flow stops
  • Resources are released when the Robomotion process ends
  • No persistent connections are maintained across flow executions

However, explicit disconnection is still recommended as a best practice for clean, maintainable flows.