Integrations overview

The KEBS Integration Architecture is a middleware-based design that sits between external application servers and the KEBS platform. It handles authentication, payload validation, data transformation, error management, and audit logging — ensuring that data entering or leaving KEBS is always clean, consistent, and traceable.

Architecture Layers

Data flows through five distinct layers as it moves between systems:

When an external system sends data to KEBS, the payload passes through a structured pipeline before being stored. This ensures data quality and consistency across all modules.

Step 1 — Payload Validation

Before any processing begins, the middleware performs two checks on the incoming request:

• Payload Size Validation — ensures the request does not exceed the allowed size limits.
• Payload Schema Validation — verifies the structure and format of the payload against the expected API schema. Malformed payloads are rejected immediately.

Step 2 — Data Processing Pipeline

Once the payload passes validation, the data moves through five sequential processing stages:

Step 3 — Staging & Consumption

After processing, data is written to the KEBS Staging Layer. The target application module (e.g., Employee Directory, Finance) then consumes data from the staging layer and makes it available to users. Staging data is cleared periodically based on the data lifecycle policy.

Supported Inbound Modules

KEBS connectors are the bridge between the middleware layer and external systems. Each connector handles authentication, field mapping, error handling, and data transformation for a specific integration target.

Connector Types

Outbound Sync

Outbound integrations push data from KEBS to external systems. Outbound sync is event-driven — triggered by specific actions within KEBS modules:

• Invoice finalization — when an invoice is approved in KEBS Finance, it can be pushed to an external accounting system.
• Project status changes — milestone completions or status updates in KEBS Projects can trigger notifications or updates in external PM tools.
• Timesheet approvals — approved time entries can be exported to external payroll or billing platforms.
• Employee data changes — certain KEBS-originated changes (e.g., project assignment, skill updates, calendar changes) can be synced outbound.

The Integration Monitor provides a centralized view of all integration activity across every connector and module. It is accessible from the KEBS Reports module and captures both inbound and outbound data flows.

What the Monitor Tracks

Outbound Pipeline Stages

When KEBS pushes data to an external system, the outbound pipeline follows these stages:

All errors encountered during integration — inbound or outbound — are logged in KEBS and an error trace is created. Notifications are automatically dispatched to the relevant teams.

Error Classification & Resolution Flow

• 1
  The system checks whether the error is a payload validation error (malformed structure, missing required fields, size limit exceeded).
• 2
  If it is a payload error, the payload details are attached to the error trace and stakeholders are notified with the specific validation failure.
• 3
  If it is not a payload error, the system searches the Error Repository for the error code to find known resolutions.
• 4
  If a match is found, the probable cause and suggested recovery steps are added to the error trace, and stakeholders are notified with actionable guidance.
• 5
  If the error is unknown (not in the repository), a new support ticket is automatically created in KEBS for investigation.
• 6
  After investigation and resolution, RCA (Root Cause Analysis) and CAPA (Corrective and Preventive Action) are recorded in the Error Repository — so future occurrences resolve faster.

Common Error Scenarios

KEBS uses the OAuth 2.0 protocol for all API integrations — both inbound and outbound. This ensures that every API call is authenticated, authorized, and encrypted without exposing long-lived credentials.

Token Lifecycle Flow

Token Best Practices

• Never hardcode tokens in source code or configuration files. Use secure vaults or environment variables.
• Implement automatic refresh — your integration client should detect 401 responses and automatically request a new token using the refresh token.
• Monitor token failures — repeated auth failures appear in the Integration Monitor and may indicate a revoked client, expired refresh token, or security incident.
• Rotate Client Secrets periodically — raise a support ticket in KEBS to rotate credentials. Plan a 48-hour window for the changeover.
• Use separate clients per integration — each external system should have its own Client ID/Secret pair for auditability and independent revocation.

SSO & User Authentication

For end-user access (as opposed to system-to-system API calls), KEBS uses Single Sign-On (SSO) in production environments. SSO leverages the employee’s email address as the unique identifier and integrates with identity providers such as Azure AD.

Master data (dropdown values, entity names, departments, regions, etc.) and API field configurations must be kept in sync between KEBS and the external system. Since these are maintained manually in both systems, a structured change management process is essential.

Change Management Rules