Python SDK
Full Documentation
This is the client SDK for EnSync engine (message delivery engine) that enables you to build an ecosystem of connected devices and services.
Installation
Usage
Importing
Default (gRPC)
WebSocket Alternative
Both clients provide the same API for publishing and subscribing to events.
gRPC Connection Options:
Production URLs automatically use secure TLS (port 443)
localhost
automatically uses insecure connection (port 50051)Explicit protocols:
grpcs://
(secure) orgrpc://
(insecure)Custom ports:
node.ensync.cloud:9090
API Reference
EnSyncEngine (gRPC - Default)
The main class that manages gRPC connections and client creation for the EnSync system. This is the default and recommended client for production use.
EnSyncWebSocketEngine (WebSocket - Alternative)
An alternative class that manages WebSocket connections and client creation for the EnSync system.
Parameters
Parameter | Type | Required | Description |
---|---|---|---|
|
| Yes | The URL of the EnSync server |
|
| No | Configuration options |
Options Dictionary:
Option | Type | Default | Description |
---|---|---|---|
|
|
| Set to true to disable TLS |
|
|
| Reconnection interval in ms |
|
|
| Maximum reconnection attempts |
Creating a Client
Initialize the engine with your server URL
Create a client with your app key
Client Creation Parameters
Parameter | Type | Required | Description |
---|---|---|---|
|
| Yes | Your EnSync application key |
|
| No | Client configuration options |
Options Dictionary:
Option | Type | Default | Description |
---|---|---|---|
|
|
| Default key used to decrypt incoming messages |
Client Returns
Returns a new EnSyncClient
instance.
Publishing Events
Publish Parameters
Parameter | Type | Required | Description |
---|---|---|---|
|
| Yes | Name of the event (e.g., "company/service/event-type") |
|
| Yes | Array of appIds (the appIds of receiving parties) |
|
| Yes | Your event data (any JSON-serializable object) |
|
| No | Control event persistence and add custom headers |
Metadata Dictionary:
Option | Type | Default | Description |
---|---|---|---|
|
|
| Whether to persist the event on the server |
|
|
| Custom headers to include with the event |
Subscribing to Events
Subscribe Parameters
Parameter | Type | Required | Description |
---|---|---|---|
|
| Yes | Name of the event to subscribe to |
|
| No | Subscription options |
Options Dictionary:
Option | Type | Default | Description |
---|---|---|---|
|
|
| Set to false for manual acknowledgment |
|
|
| Custom decryption key for this subscription |
Subscription Methods
Event Structure
When you receive an event through a subscription handler, it contains:
Closing Connections
Error Handling
The SDK raises EnSyncError
for various error conditions. Always wrap your code in try-except blocks to handle potential errors gracefully.
Common error types:
Error Type | Description |
---|---|
| Connection or authentication issues |
| Problems publishing events |
| Subscription-related errors |
| Other errors |
Complete Examples
Quick Start
Publishing Example
Subscribing Example
Best Practices
Connection Management
Store connection credentials securely using environment variables
Implement proper reconnection logic for production environments
Always close connections when they're no longer needed
Event Design
Use hierarchical event names (e.g.,
domain/entity/action
)Keep payloads concise and well-structured
Consider versioning your event schemas
Security Best Practices
Never hardcode app keys or secret keys
Use environment variables or secure key management solutions
Implement proper authentication and authorization
Consider encrypting sensitive payloads
Performance Optimization
Batch events when possible instead of sending many small messages
Consider message size and frequency in high-volume scenarios
Use appropriate TTL values for your use case
Implement proper error handling and retry logic
Subscription Control
The SDK provides methods to pause, continue, and replay events, which is useful for managing event processing flow.
What Pause and Continue Do
When you create a client using engine.create_client()
, that client receives a unique client_id
. This client_id
(not the app_key
) identifies your specific client instance on the EnSync server.
Pause: Temporarily stops the client from receiving new events from the server. The subscription remains active on the server, but events are not delivered to this specific client instance. Other clients with the same
app_key
but differentclient_id
will continue receiving events normally.Continue: Resumes event delivery to the paused client. Any events that occurred during the pause (depending on server settings and TTL) may be delivered once the subscription is continued.
Replaying Events
The replay command allows you to request a specific event to be sent again, even if it has already been processed. Unlike regular event handling which delivers events through the event handler, the replay function returns the event data directly to your code. This is useful for:
Retrieving specific events for analysis or debugging
Accessing historical event data without setting up a handler
Examining event content without processing it
Getting event data synchronously in your code flow
The replay command returns the complete event object with its payload:
Direct Access vs Handler Processing:
Regular event subscription:
Replay function:
Deferring Events
The defer method allows you to postpone processing of an event for a specified period. This is useful when:
You need more time to prepare resources for processing
You want to implement a retry mechanism with increasing delays
You need to wait for another system to be ready
You want to implement rate limiting for event processing
The defer method returns an object with status information:
Discarding Events
The discard method allows you to permanently reject an event without processing it. This is useful when:
The event contains invalid or corrupted data
The event is no longer relevant or has expired
The event was sent to the wrong recipient
You want to implement a filtering mechanism
The discard method returns an object with status information:
Use cases for pause/continue:
Temporary maintenance or system updates
Rate limiting or throttling event processing
Implementing backpressure mechanisms
Batch processing of events
Implementation Details
Pause/continue operations are performed at the subscription level, not the client level
The server maintains the subscription state even when paused
Pausing affects only the specific subscription instance, not all subscriptions for the client
Events that arrive during a pause may be delivered when continued (depending on TTL settings)
The pause state is not persisted across client restarts or reconnections