CORTEX Service Public API
🌐 Public API Overview
❓ What Is the Public API?
Our Public API is a RESTful interface designed to enable seamless integration between 3rd party platforms (such as Oracle, Maximo, and others) and our CORTEX Service. The API supports essential asset management functions, enabling interoperability, automated workflows, and consistent data exchange across your enterprise systems.
💡 Why Use the Public API?
Benefit | Description |
|---|---|
Centralized Management | Synchronize asset information and work orders between your platform and external systems. |
Automation | Enable automated creation, updates, and status tracking of work orders. |
Scalable Integration | Designed to support thousands of assets and high-frequency transactions. |
Extensible | Can be integrated with a variety of 3rd party platforms solutions, not limited to any specific vendor. |
clipboard Subscription Requirements
Requirement | Details |
|---|---|
CORTEX Service Subscription | You must already have either a CORTEX Service Connect or a CORTEX Service maintenance subscription. |
One-time Integration fee | Paid once, workshop configuration, provisioning and support. |
Annual API Subscription | Additional CORTEX Service subscription. Paid annually. |
*All 3 requirements are separate fees.
⚙️ Key Functionalities
📦 Asset Management
Function | Description |
|---|---|
Retrieval of Asset Details | Query asset records for information synchronization. |
New Asset Creation | Register new assets in the external system via API using a predefined structure. |
Asset Identification | Assets are referenced using an external platform ID. Our API supports mapping with a built-in lookup table on CORTEX Service. |
memo Work Order Management
Function | Description |
|---|---|
Work Order Creation | Create new work orders in the 3rd party system via API. |
Work Order Updates | Sync status and detail changes between systems. Work orders can be "pushed" to our service, and clients can poll for status updates. |
Work Order Visibility | Work order statuses from the external platform can be integrated and made visible in your interfacing systems. |
⚠️ Alarm & Fault Handling
Feature | Description |
|---|---|
Generic Asset Faults | Faults are generally flagged at the asset level. |
Observations & Alerts | Observations can include system-specific alerts and carry an ‘attention flag’ for operational issues. |
Custom Thresholds | While asset fault states are generic, observations allow for marking operational vs. critical alarms. |
🤝 Interaction Mechanisms
Mechanism | Details |
|---|---|
API-First | All integrations utilize RESTful API endpoints. |
Payload Format | All data is exchanged in JSON format. |
Real-Time or Polling | Synchronous real-time transactions are supported via REST API. |
🔒 Security
Feature | Details |
|---|---|
Supported Authentication Mechanisms |
|
No additional network appliances required | Direct access—no firewalls, NATs, or VPNs needed to reach public endpoints (subject to standard internet security best practices). |
⚡ Performance & Limits
Metric | Details |
|---|---|
Payload Size | Configurable, default request limit is 5 MB; no default response limit. |
API Rate Limits | Default 60 requests per minute and 3,000 requests per day (customizable). |
Concurrent Connections | No explicit limit, but rate limits apply. |
Response Time | 50ms–2,000ms typical; peak responses may be longer when retrieving complex or large datasets. |
Scalability | Supports 5,000–30,000 assets typical per implementation. |
🔎 Typical Integration Scenarios
🔃 Example 1: Asset Synchronization
Push asset details from 3rd party platform (such as Oracle or Maximo) to CORTEX Service using POST /assets
CORTEX Service confirms creation/updates via JSON response with external asset ID references.
📅 Example 2: Work Order Lifecycle
Create Work Order in your platform, trigger a push to CORTEX Service using POST /workorders
Update status by patching the work order via PATCH /workorders/{id}
Poll status periodically using GET /workorders/{id}
✅ Applicability
This integration pattern is platform independent, provided they support API capabilities and similar data models.
📃 API Documentation
For detailed request/response schemas, authentication workflows, and up-to-date endpoint definitions, please consult the API Swagger Documentation available on your CORTEX Service Instance. https://swagger.io
📜 Scope of Work
Integration task | Done by |
REST API documentation and introductory support. | CORTEX SERVICE TEAM
|
Provide a Sandbox/demo/test environment for integration testing. | CORTEX SERVICE TEAM |
Mapping of entities (Assets, Work-orders, etc.) | CUSTOMER/AIRPORT/3RD PARTY and CORTEX SERVICE TEAM |
Create and own the API script and logic that makes use o the CORTEX Service Public API on the Customer/External Platform | CUSTOMER/AIRPORT/3RD PARTY |
Test-environment evaluation for communication between CORTEX Service and Foreign System | CUSTOMER/AIRPORT/3RD PARTY and CORTEX SERVICE TEAM |
Go live* on production instance | CUSTOMER/AIRPORT/3RD PARTY and CORTEX SERVICE TEAM |
*Post launch support can be provided when necessary.
❓ Further Questions or Assistance
For further questions or assistance, please contact us through our Jira Service Management portal or contact your local sales representative.
https://adbsafegate.atlassian.net/servicedesk/customer/portal/11