.png)
Fiix Integration Guide
Connect Fiix CMMS with enterprise applications through its REST API, scheduled synchronization workflows, and Martini-managed API orchestration.
Fiix integration options at a glance
Fiix primarily supports API-based integration through its REST API, which can expose Assets, Work Orders, Maintenance Requests, Parts, Locations, Users, and related maintenance data. Fiix API access requires account-level integration credentials, although the precise credential exchange should be confirmed for each tenant. Webhook or outbound-callback support was not conclusively verified, so scheduled polling with pagination and synchronization watermarks is the safer default for change detection. Martini can consume Fiix REST endpoints, expose a controlled REST API for upstream applications, map payloads to canonical models, and orchestrate downstream ERP, service, reporting, or analytics workflows. Direct database access, GraphQL, SOAP, and general-purpose bulk APIs were not confirmed.
| Integration point | Supported by Fiix? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Retrieve Assets, Work Orders, Maintenance Requests, Parts, Locations, Users, and maintenance data; create or update supported Work Orders and Maintenance Requests. | Martini can consume Fiix REST endpoints from workflows, transform payloads, expose standardized REST APIs, and orchestrate downstream calls. |
| Authentication | Limited | Fiix API access requires account-level integration credentials, but the current credential exchange must be confirmed for the tenant. | Martini stores environment-specific credentials in secure configuration or secrets and keeps authentication separate from workflow mappings. |
| Scheduled synchronization | Yes | Poll Fiix for changed Assets, Work Orders, Maintenance Requests, Parts, or other resources when event delivery is unavailable or unconfirmed. | Martini scheduler-triggered workflows can retrieve pages, maintain watermarks, apply overlap windows, and resume failed synchronization runs. |
| Webhooks / outbound callbacks | Not confirmed | Tenant-specific outbound notifications may exist for selected events, but universal Fiix webhook coverage was not verified. | Martini can receive webhook-style notifications when Fiix confirms and enables them; otherwise it can use scheduled polling. |
| Bulk / asynchronous APIs | Not confirmed | No general-purpose Fiix bulk or asynchronous API was verified; large loads should use paginated workflows unless Fiix confirms another endpoint. | Martini can process bounded pages, checkpoint progress, retry failed pages, and separate invalid objects from successful results. |
| File / attachment APIs | Not confirmed | Documents or media may be available in selected Fiix product areas, but a generally documented attachment API was not verified. | Martini can handle files when a supported Fiix endpoint is confirmed, but attachment synchronization requires separate tenant-level validation. |
| GraphQL APIs | Not confirmed | No official Fiix GraphQL API documentation was verified; new integrations should be planned around REST. | Martini supports GraphQL generally, but this Fiix integration should not assume GraphQL endpoints exist. |
| SOAP APIs | Not confirmed | No official Fiix SOAP API documentation was verified. | Martini supports SOAP consumption generally, but no Fiix SOAP integration should be designed without vendor confirmation. |
| Database access | No | Direct customer database or analytics access was not confirmed and is not the recommended integration route. | Martini should use Fiix’s supported API surface rather than querying the underlying CMMS database. |
How Fiix exposes data and business events
Fiix REST APIs
Fiix’s documented integration model is API-oriented. Its REST API can provide access to Assets, Work Orders, Maintenance Requests, Parts, Locations, Users, and other maintenance-related resources, subject to tenant permissions, enabled modules, API version, and the exact resource paths available.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates with environment-specific Fiix integration credentials, calls the required REST resource, handles pagination and response validation, maps the payload to a canonical or target schema, and records identifiers and checkpoints for traceability.
Implementation sequence
Scheduled Fiix synchronization
Scheduled polling is the recommended fallback when Fiix webhook or outbound-callback coverage is unavailable or has not been confirmed. Modified timestamps, status filters, or stable identifiers may support incremental extraction for individual resources.
Martini implementation pattern
Martini implementation pattern: a scheduler starts a workflow, the workflow reads the stored watermark, retrieves changed objects in bounded pages, applies an overlap window and deduplication, and advances the checkpoint only after successful processing.
Implementation sequence
Fiix webhook-style notifications
Fiix webhook or outbound-callback support was not conclusively verified and should not be assumed for all object changes. If the tenant confirms notifications for selected events, they can reduce polling latency for those events.
Martini implementation pattern
Martini implementation pattern: Martini exposes a secured webhook-facing REST API, validates the Fiix notification, retrieves the current resource when necessary, and invokes the same mapping and business-rule workflow used by scheduled synchronization. Unsupported or unconfirmed events remain on a polling design.
Implementation sequence
Common Fiix integration patterns
Pattern 1: Sync Fiix Work Orders to an enterprise system
When to use this pattern
Use this pattern when maintenance execution data must be synchronized with SAP S/4HANA, ServiceNow, Salesforce, reporting platforms, or another enterprise application. It supports incremental extraction and restartable processing rather than repeated full loads.
Integration direction
Example Mapping
| Fiix Field | Canonical Field | Target Field |
|---|---|---|
| Work Order identifier | maintenanceWorkOrderId | externalWorkOrderId |
| status | maintenanceStatus | workOrderStatus |
| priority | priorityCode | priority |
| completion date | completedAt | actualCompletionDate |
Martini implementation pattern
A scheduled Martini workflow reads the watermark, retrieves changed Work Orders page by page, maps statuses and priorities through explicit business rules, enriches references to Assets and Locations, and writes the target payload. It stores Fiix identifiers and advances the checkpoint only after successful processing; throttling and transient failures are retried without replaying completed records.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination and checkpointing
- data mapping
- business rules
- error handling
Pattern 2: Create Fiix Work Orders from service requests
When to use this pattern
Use this pattern when Salesforce Cases, ServiceNow requests, or another enterprise process needs to initiate maintenance work in Fiix. It is appropriate when the tenant exposes the required create operation and the calling process can supply valid references.
Integration direction
Example Mapping
| Fiix Field | Canonical Field | Target Field |
|---|---|---|
| request description | maintenanceDescription | description |
| requested asset | assetId | Asset reference |
| priority | priorityCode | priority |
| requested date | requestedAt | requested date |
Martini implementation pattern
A Martini REST API receives the request, validates required fields and referenced Assets, Locations, Users, and Parts, then calls the Fiix REST operation for a Work Order or Maintenance Request. The workflow returns the Fiix identifier, stores the cross-system correlation key, and distinguishes validation failures from uncertain timeouts before retrying a create operation.
Martini capabilities used
- API exposure
- workflow orchestration
- validation
- data mapping
- business rules
- idempotency and error handling
Pattern 3: Synchronize Fiix Parts with an ERP
When to use this pattern
Use this pattern when maintenance inventory, spare-part consumption, quantities, locations, or cost-related information must be coordinated with NetSuite, SAP S/4HANA, or Microsoft Dynamics 365.
Integration direction
Example Mapping
| Fiix Field | Canonical Field | Target Field |
|---|---|---|
| Part identifier | partNumber | itemCode |
| quantity | quantity | quantity |
| location | storageLocation | warehouseLocation |
| cost | maintenanceCost | transactionCost |
Martini implementation pattern
Martini retrieves the Fiix Parts and any confirmed inventory or consumption fields, normalizes units and identifiers, applies business rules for target locations and adjustments, and sends bounded batches to the ERP. The workflow records source identifiers, isolates invalid part mappings, retries transient target failures, and preserves the last successful page.
Martini capabilities used
- API consumption
- batch workflow orchestration
- data transformation
- business rules
- checkpointing
- retry handling
Pattern 4: Deliver Fiix maintenance data to analytics
When to use this pattern
Use this pattern when operational teams need asset history, maintenance backlog, preventive-maintenance performance, completion dates, or cost-related reporting in Microsoft Power BI, Tableau, or an intermediate data platform.
Integration direction
Example Mapping
| Fiix Field | Canonical Field | Target Field |
|---|---|---|
| Asset identifier | assetId | AssetKey |
| Work Order status | maintenanceStatus | Status |
| completion date | completedAt | CompletionDate |
| Location identifier | locationId | LocationKey |
Martini implementation pattern
A scheduler starts a Martini extraction workflow that retrieves Fiix Assets and Work Orders over a controlled time window, maps them to a reporting schema, and delivers the result through the selected analytics architecture. Counts, windows, source identifiers, and failures are logged so a failed page or time range can be replayed without duplicating completed loads.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- JSON handling
- checkpointing
- monitoring and error handling
Applications commonly integrated with Fiix
Fiix can be integrated with adjacent enterprise applications where maintenance execution, asset information, inventory, service operations, or reporting need to be coordinated. These patterns use Fiix’s supported API surface and should be validated against the customer’s enabled modules, permissions, and target-system requirements.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| SAP S/4HANA | Synchronize equipment, maintenance costs, spare parts, purchasing, and work-completion information between enterprise asset processes and Fiix. | SAP S/4HANA → Martini → Fiix | Martini exposes or consumes REST APIs, validates master-data references, maps SAP identifiers to Fiix Assets, Parts, Locations, and Work Orders, and routes failures to an exception workflow. Completion and cost data can be returned to SAP through a separate workflow. |
| Microsoft Dynamics 365 | Connect maintenance activity with service operations, supply-chain processes, customer information, or finance workflows. | Microsoft Dynamics 365 → Martini → Fiix | A Martini API or scheduled workflow receives Dynamics data, applies field and status mappings, and calls Fiix REST operations. Fiix changes can be polled incrementally and transformed back into Dynamics-compatible payloads. |
| Salesforce | Create Fiix maintenance requests from customer cases and return Work Order progress or completion details to customer-facing teams. | Salesforce → Martini → Fiix | Martini receives a Salesforce event or API request, validates the Asset, Location, priority, and description, then creates or updates the appropriate Fiix object when tenant permissions allow it. Status updates are reconciled using stable identifiers and an incremental workflow. |
| ServiceNow | Coordinate incidents, facilities requests, or service tasks with Fiix maintenance execution. | ServiceNow → Martini → Fiix | Martini maps ServiceNow request or task data into Fiix Maintenance Requests or Work Orders, validates related objects, and sends status and completion updates back to ServiceNow. Retries and correlation keys prevent duplicate submissions. |
| Jira | Link engineering or product issues with Fiix Work Orders and synchronize status, ownership, and references. | Jira → Martini → Fiix | A Martini workflow transforms Jira issue fields into Fiix maintenance payloads and stores cross-system identifiers. A scheduled reconciliation process compares status and ownership changes while isolating validation failures. |
| NetSuite | Synchronize spare-parts inventory, purchasing, vendors, and maintenance-related costs. | Fiix → Martini → NetSuite | Martini retrieves Fiix Parts and relevant maintenance-consumption data, maps part numbers, quantities, locations, units, and costs to NetSuite structures, and writes checkpointed batches with duplicate protection. |
| Microsoft Power BI | Provide dashboards for asset availability, preventive-maintenance compliance, backlog, downtime, and Work Order performance. | Fiix → Martini → Microsoft Power BI | A scheduled Martini workflow extracts Fiix Work Orders, Assets, statuses, completion dates, and cost-related fields, transforms them into a reporting schema, and delivers them through the selected data-platform architecture. |
| Tableau | Analyze maintenance performance, asset history, costs, and technician or location trends. | Fiix → Martini → Tableau | Martini retrieves and normalizes Fiix data, preserves stable identifiers and reporting timestamps, and loads the resulting dataset into the customer’s selected warehouse or Tableau ingestion path with restartable checkpoints. |
How to build a Fiix integration in Martini
Objective
Establish Fiix API access without coupling credentials to workflow logic.
Instructions in Martini
- Confirm the tenant’s current Fiix API credential exchange and permissions.
- Store environment-specific credentials in Martini secrets or secure configuration.
- Use separate development, test, and production credentials where available.
Objective
Select an invocation model that matches the confirmed Fiix capabilities and required latency.
Instructions in Martini
- Use a scheduler for incremental polling when webhooks are unavailable or unconfirmed.
- Use a secured Martini REST API for upstream requests that create or update Fiix data.
- Use Fiix notifications only after tenant-specific callback support is verified.
Objective
Read Fiix resources reliably and preserve progress across large or interrupted synchronizations.
Instructions in Martini
- Call the confirmed Fiix REST resources for Assets, Work Orders, Maintenance Requests, Parts, Locations, or Users.
- Implement the tenant’s actual pagination model and bounded request concurrency.
- Store a watermark, last processed identifier, or time window after successful processing.
Objective
Coordinate validation, enrichment, transformation, target writes, and recovery behavior.
Instructions in Martini
- Separate retrieval, validation, mapping, target delivery, and checkpoint updates into clear workflow stages.
- Resolve required Asset, Location, User, Part, or other references before processing dependent objects.
- Route invalid objects and non-transient failures to an exception path.
Objective
Create stable target payloads while accommodating Fiix-specific identifiers, statuses, and custom fields.
Instructions in Martini
- Map Fiix fields to a canonical maintenance model before target-specific mapping.
- Translate status, priority, date, identifier, quantity, and location values explicitly.
- Preserve source identifiers and relevant unknown fields where forward compatibility requires it.
Objective
Prevent invalid or duplicate maintenance transactions.
Instructions in Martini
- Validate required fields and tenant-specific permissions before create or update operations.
- Use deterministic correlation keys and stored Fiix identifiers for idempotency.
- Define handling for inactive, archived, deleted, reassigned, or missing related objects.
Common Fiix data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Assets | Represent equipment or maintainable items whose maintenance activity is tracked. | SAP S/4HANA, Microsoft Dynamics 365, Salesforce, Power BI, Tableau | Martini retrieves or receives Assets through confirmed Fiix REST resources, maps durable identifiers and locations, and synchronizes master data before dependent Work Orders. |
| Work Orders | Represent planned or reactive maintenance work, including status, priority, assignments, costs, and completion information. | SAP S/4HANA, ServiceNow, Salesforce, Jira, Power BI | Martini validates related Assets, Locations, Users, and Parts, maps statuses explicitly, applies idempotency keys, and creates, updates, or exports Work Orders through workflows. |
| Maintenance Requests | Capture requests for maintenance that may be reviewed and converted into Work Orders. | Salesforce, ServiceNow, Microsoft Dynamics 365, SAP S/4HANA | Martini receives requests through an API or scheduled process, validates required fields, maps them to Fiix operations, and returns the Fiix identifier and status where supported. |
| Parts | Represent inventory items and spare parts used during maintenance activities. | NetSuite, SAP S/4HANA, Microsoft Dynamics 365, Power BI | Martini maps part numbers, quantities, locations, units, and cost-related fields, then sends checkpointed inventory or consumption data to downstream systems. |
| Locations | Associate Assets and maintenance activity with physical or organizational locations. | SAP S/4HANA, Microsoft Dynamics 365, ServiceNow, reporting platforms | Martini synchronizes Locations as reference data, preserves Fiix identifiers, and validates references before processing dependent objects. |
| Users | Represent technicians, supervisors, and other personnel involved in maintenance operations. | ServiceNow, Salesforce, Microsoft Dynamics 365, reporting platforms | Martini maps user identifiers, assignments, and relevant status fields while applying tenant-specific security and data-minimization rules. |
Authentication and security considerations
Credential handling
Fiix API access requires account-level integration credentials, but the exact current exchange should be confirmed for each tenant. Martini should keep these credentials in environment-specific secrets rather than workflow definitions.
Least privilege
- Request only the Fiix objects and operations required by the integration.
- Use separate credentials for development, testing, and production.
- Do not log access tokens, secrets, or sensitive maintenance details.
API façade security
When Martini exposes an API for Fiix operations, secure and authorize the façade independently from Fiix credentials. Validate callers and payloads before invoking Fiix.
Operational considerations for Fiix integrations
Limits and pagination
Confirm Fiix request, concurrency, quota, and pagination behavior for each tenant and resource. Use bounded concurrency, stable ordering, and checkpointed pages.
Incremental processing
Prefer supported modified-date or status filters, use an overlap window, and deduplicate by Fiix identifier and update timestamp. Do not advance a checkpoint until the corresponding target writes succeed.
Reliability and idempotency
- Retry transient HTTP failures and throttling responses with bounded backoff.
- Separate authentication, validation, missing-reference, and server failures.
- Use correlation keys to prevent duplicate Work Orders and Maintenance Requests.
Schema and testing
Confirm resource names, API versions, custom fields, enumerations, and related-object behavior in the tenant documentation. Test mappings when statuses, fields, or enabled modules change.
Observability
Capture synchronization windows, object types, identifiers, request correlation data, and counts for retrieved, created, updated, skipped, and failed objects.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini coordinates Fiix API calls, enterprise APIs, validation, transformations, business rules, and downstream writes in maintainable workflows rather than scattering logic across scripts.
Reliable synchronization
Checkpointing, pagination, retries, idempotency, and exception paths provide a more controlled operating model for Work Orders, Assets, Parts, and related data than ad hoc polling code.
Reusable API assets
Martini can expose a stable API façade for Fiix and reuse common mapping, security, and error-handling logic across service, ERP, inventory, and reporting integrations.
Environment-aware delivery
Credentials and configuration remain separate from orchestration logic, supporting controlled promotion across environments and easier credential rotation.
Frequently asked questions
Fiix is primarily integrated through its REST API. Enterprise systems can retrieve Assets, Work Orders, Maintenance Requests, Parts, Locations, Users, and related maintenance data, and can create or update supported resources when tenant permissions allow. Scheduled polling with pagination and checkpoints is the safest general synchronization approach because universal Fiix webhook support was not verified.
Yes. Martini can consume Fiix REST APIs from workflows, expose REST APIs for upstream applications, transform Fiix payloads, and orchestrate synchronization with ERP, service, inventory, reporting, and analytics platforms. The exact Fiix resources and credential exchange should be confirmed for the tenant.
No. A dedicated Fiix connector is not required. Martini can integrate using Fiix’s confirmed REST API and account-level integration credentials, with scheduled workflows or tenant-confirmed callback mechanisms used for synchronization.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Fiix. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Fiix, cloud infrastructure, or other third-party systems based on subscription, API usage, and deployment model.
New projects should use Fiix’s REST API and Martini workflows. Scheduled synchronization is appropriate when changes must be polled. GraphQL, SOAP, general-purpose bulk APIs, direct database access, and broadly available attachment APIs were not confirmed for Fiix and should not be assumed.
Fiix webhook or outbound-callback coverage was not conclusively verified. Do not assume all object changes can trigger Martini directly. If the tenant confirms notifications for selected events, Martini can receive them through a secured API; otherwise, use timestamp-, identifier-, or status-based polling.
Martini can use modified-date or status filters where available, retrieve data in pages, maintain a synchronization watermark, and apply an overlap window. Stable Fiix identifiers, deterministic correlation keys, and separate create, update, and reconciliation logic help prevent duplicate Work Orders or Maintenance Requests.
Yes. Martini can expose a REST API that standardizes access to Fiix, validates requests, applies business rules, maps enterprise payloads to Fiix structures, and hides tenant-specific API details from upstream applications. This façade does not require a native Fiix connector.
Related Martini documentation
API Integration
Workflows
Connect Fiix with your enterprise systems
Use Martini to build a secure, maintainable Fiix integration around REST APIs, scheduled workflows, data mapping, and reliable synchronization.