Communication architecture
Key points:- Connectors poll for tasks (pull model, not push)
- Tasks include: Sync, Grant, Revoke, CreateAccount, DeleteResource, RotateCredential
- Results upload via streaming (c1z files in 512KB chunks)
- Heartbeats keep tasks alive during long operations
BatonServiceClient
The client interface used by connectors:Task types
Sync tasks
Full or targeted data sync from the external system:Grant task
Provision access to a user:Revoke task
Remove access from a user:CreateAccount task
Provision a new user account (JIT):DeleteResource task
RotateCredential task
Task lifecycle
Polling loop
Heartbeat intervals
Task completion
Upload mechanism
Sync results (c1z files) upload via streaming:- Streaming (not buffered in memory)
- 512KB chunks
- Resumable on network errors
- Compressed c1z format
Authentication
Client credentials
Connectors authenticate using OAuth2 client credentials:- Token acquisition from C1’s OAuth endpoint
- Token refresh before expiration
- Token injection into request metadata
Host identification
Connectors identify themselves to C1:Error handling
Retryable vs non-retryable
Error flow
Annotations for error context
Return annotations to provide context:Debugging API communication
Enable debug logging
- Task received notifications
- Heartbeat timing
- Upload progress
- API response codes
Common issues
Quick reference
Daemon mode checklist
Task processing flow
- Hello - Connector identifies itself
- GetTask - Poll for work (returns task or empty)
- Process - Execute sync/grant/revoke/etc
- Heartbeat - Keep task alive during processing
- FinishTask - Report success or failure
- Upload - Send c1z file (sync tasks only)
SDK handles
- OAuth2 token management
- Connection pooling
- Heartbeat scheduling
- Chunk-based uploads
- Retry with backoff
- Error classification