External Systems Integration

cidaas integrates with external systems to provide a complete identity and access management solution. This guide covers integration patterns, data flows, and system ownership.

Integration Patterns

Webhooks (Event-Driven)

cidaas sends webhook events to external systems when user actions occur.

When to Use: Real-time synchronization, immediate notifications

Flow: User action → cidaas → Webhook event → External system

API-Based

Your application calls cidaas APIs to retrieve or update user data.

When to Use: On-demand data access, user-initiated actions

Flow: Application → cidaas API → Get/Update user data

Batch Synchronization

Periodic batch jobs synchronize data between systems.

When to Use: Large data volumes, non-critical timing

Inbound user provisioning

External systems can push users and groups into cidaas (opposite direction from webhooks):

• SCIM (identity provider → cidaas): Your identity provider or SCIM client provisions users and groups via the SCIM 2.0 API. See SCIM 2.0 User Provisioning.
• cnips.io / User APIs (HR, ERP → cidaas): For synchronization, transformation, or workflows from business systems, use cnips.io pipelines with the official cidaas User and Group APIs — not SCIM.

Webhooks and API-based patterns above cover outbound flows (cidaas → external systems). SCIM and cnips.io cover inbound provisioning into cidaas.

System ownership

Ownership is situational — there is no single black-and-white rule. Decide per attribute and per integration which system is authoritative for create, update, and delete, and document that in your project.

Often in cidaas (identity layer):

• Authentication credentials and login identifiers
• Core profile used for SSO (e.g. name, email, phone) when cidaas is the CIAM
• Verification / MFA status for methods managed in cidaas

Often in external systems (business layer):

• Orders, preferences, CRM enrichment, application-specific state
• Historical or analytical records

Common patterns (pick what fits):

Pattern	When
cidaas as identity master after go-live	Greenfield CIAM or completed cutover — apps write identity changes back to cidaas
Co-sources during bidirectional migration	Phased app cutover — both IdPs stay in sync until the last app moves; then stop sync and nominate a master (bidirectional sync)
External IdP / HR as source for workforce	Inbound SCIM or cnips.io pipelines provision into cidaas; cidaas still issues tokens for apps
CRM owns commerce profile	Link via sub; sync selected fields with webhooks or APIs without duplicating full CRM data in cidaas

Capture the decision in the Integration Checklist (§6 System landscape).

Data Flow

User Registration

User → cidaas → Webhook: ACCOUNT_CREATED_WITH_CIDAAS_IDENTITY → CRM, Marketing Tools

Data Transferred: sub, email, name, createdTime, custom fields

User Profile Update

User → cidaas → Webhook: ACCOUNT_MODIFIED → CRM, Reporting

Data Transferred: Updated fields, timestamp, sub

User Login

User → cidaas → ID Token → Application Backend → Analytics

Data Transferred: User identifier, email, name (from ID token), login timestamp

Common Integration Scenarios

CRM Integration

When Called: User registration, profile updates, deletion

Key Data:

• sub → Customer ID (primary link)
• email, given_name, family_name
• email_verified, createdTime

Webhook Events: ACCOUNT_CREATED_WITH_CIDAAS_IDENTITY, ACCOUNT_MODIFIED, ACCOUNT_DELETED

Marketing Tools

When Called: User registration, consent changes, profile updates

Key Data:

• sub, email, mobile_number
• customFields.newsletter_consent, locale

Webhook Events: ACCOUNT_CREATED_WITH_CIDAAS_IDENTITY, CONSENT_ACCEPTED, CONSENT_REVOKED

Reporting/Analytics

When Called: User login, registration, actions

Key Data:

• Event type, timestamp, user identifier
• Device info, location, authentication method

Webhook Events: LOGIN_WITH_CIDAAS, ACCOUNT_CREATED_WITH_CIDAAS_IDENTITY, ACCOUNT_MODIFIED

Key Webhook Events

Event	When	Use Case
ACCOUNT_CREATED_WITH_CIDAAS_IDENTITY / ACCOUNT_CREATED_WITH_SOCIAL_IDENTITY	New registration	Create records in CRM, marketing
ACCOUNT_MODIFIED	Profile change	Sync updates to external systems
ACCOUNT_DELETED	Account deletion	Mark records inactive
LOGIN_WITH_CIDAAS / LOGIN_WITH_SOCIAL	Successful login	Track activity, update last login
CONSENT_ACCEPTED	Consent accepted	Update marketing preferences
CONSENT_REVOKED	Consent revoked	Update marketing preferences / suppressions

For complete webhook documentation (including the full event catalog), see Webhook Management.

Next steps

Use the high-level Integration Checklist for kickoff discovery (system landscape, ownership, patterns). Then:

• Configure webhooks in Trustdesk under Integrations → Webhooks (cidaas 4.x). See Introducing Trustdesk.
• Review User Management Flows