.png)
MRI Software Integration Guide
MRI Software integrates with enterprise systems through product-specific APIs, authentication models, scheduled data exchanges, and selectively available file or callback mechanisms.
MRI Software integration options at a glance
MRI Software offers a portfolio of product-specific APIs and integration services rather than one uniform platform interface. Confirmed REST API availability, object coverage, API versions, and tenant permissions depend on the MRI product and deployment. Authentication may use OAuth 2.0, client credentials, API keys, or product-specific permissions. MRI products may also support scheduled exports, file exchanges, callbacks, or approved reporting connections, but these mechanisms require product-level verification. Martini can consume confirmed MRI APIs, run scheduled synchronization workflows, map product payloads to canonical models, expose normalized REST APIs, and process approved files or database feeds.
| Integration point | Supported by MRI Software? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Limited | MRI provides product-specific REST APIs and integration services for selected applications, objects, and tenants. Use them for Properties, Units, Tenants, Leases, Work Orders, and other objects only after confirming product coverage. | Martini can consume a confirmed MRI REST API, handle authentication and pagination, map payloads, apply business rules, and expose a normalized REST API to downstream systems. |
| GraphQL APIs | Not confirmed | No product-wide MRI GraphQL API was confirmed in the research. GraphQL should not be assumed for MRI integrations. | Martini can consume GraphQL APIs generally, but an MRI GraphQL endpoint must be confirmed before this approach is designed. |
| SOAP APIs | Not confirmed | SOAP may exist in selected legacy or product-specific MRI integrations, but current support was not verified. | Martini can consume SOAP services when MRI provides a supported WSDL and endpoint, but this requires product-level confirmation. |
| Webhooks and outbound callbacks | Not confirmed | Some MRI products or partner programs may provide event notifications, callbacks, or integration queues, but universal event coverage was not confirmed. | If MRI provisions callbacks or webhooks, Martini can receive them through an API or workflow trigger and retrieve the authoritative resource before processing it. |
| Bulk, asynchronous, or batch APIs | Not confirmed | A product-wide bulk API was not confirmed. Large exchanges may instead use pagination, scheduled reports, exports, or product-specific batch services. | Martini can orchestrate batch workflows, checkpoints, pagination, and reconciliation when the selected MRI product exposes those mechanisms. |
| File and attachment APIs | Limited | MRI products manage property and operational documents, but a common product-wide attachment API was not verified. Confirm upload, download, import, export, and URL behavior for the selected product. | Martini can process approved files and attachment endpoints, transfer metadata and content separately, validate file properties, and retry or reconcile failed transfers. |
| Database and analytics access | Not confirmed | Direct database access should not be assumed for hosted MRI environments. An approved reporting database, warehouse feed, or customer-managed connection must be explicitly provisioned. | Where MRI provides an approved SQL or JDBC connection, Martini can query or write through database workflows while applying security, scheduling, and reconciliation controls. |
| Authentication | Limited | Authentication varies by product and API and may involve OAuth 2.0, client credentials, API keys, tenant context, product roles, and API scopes. | Martini can store credentials and tokens in environment configuration or secrets management, configure API authentication, and pass tenant or organization context as required. |
How MRI Software exposes data and business events
MRI Software REST APIs
MRI Software provides product-specific REST APIs and integration services, but available resources, operations, versions, and tenant permissions vary by MRI product and deployment. REST access should be confirmed before relying on a particular object or filter.
Martini implementation pattern
Martini implementation pattern: Martini authenticates to the provisioned MRI endpoint, retrieves pages or filtered changes, validates the product payload, maps it to a canonical model, applies business rules, and writes the result to downstream applications or a data store. For writes, the workflow retains MRI identifiers and correlation data for idempotency and reconciliation.
Implementation sequence
MRI Software file and attachment exchanges
MRI products commonly manage property and operational documents, and selected products may expose file imports, exports, document endpoints, or attachment operations. A common product-wide attachment API was not confirmed, so the available exchange must be validated for the selected product.
Martini implementation pattern
Martini implementation pattern: Martini receives or retrieves an approved MRI file or attachment exchange, validates metadata and content, maps the parent object and file identifiers, transfers content to the target, and records checksums or source identifiers for duplicate prevention. File access, size limits, URL expiration, and permissions should be confirmed.
Implementation sequence
MRI Software scheduled synchronization
When the selected MRI product does not provide usable event notifications, scheduled API retrieval, reports, exports, or file exchanges can support incremental synchronization. The exact change filter, export watermark, or report mechanism must be confirmed with MRI.
Martini implementation pattern
Martini implementation pattern: A scheduled Martini workflow uses a modified timestamp, version, change token, server-side filter, export watermark, or overlap window to retrieve changes. It checkpoints progress, performs idempotent upserts, records failures by page or object, and supports a later reconciliation run.
Implementation sequence
Common MRI Software integration patterns
Pattern 1: Synchronize Properties and Units
When to use this pattern
Use this pattern when MRI is the operational source for property and unit information and another application or warehouse needs a consistent real-estate model. It is suitable for scheduled incremental synchronization where universal MRI event coverage is not available.
Integration direction
Example Mapping
| MRI Software Field | Canonical Field | Target Field |
|---|---|---|
| Property.identifier | propertyId | External Property ID |
| Property.name | propertyName | Property Name |
| Unit.identifier | unitId | External Unit ID |
| Unit.status | unitStatus | Availability or Unit Status |
Martini implementation pattern
A scheduled Martini workflow retrieves paginated Properties and Units using the confirmed MRI filter or export strategy. It normalizes identifiers and statuses, excludes or marks inactive Units according to business rules, performs idempotent target upserts, stores a checkpoint, and sends failed pages to a retry or reconciliation path.
Martini capabilities used
- workflows
- scheduling
- API consumption
- pagination and checkpoints
- data mapping
- business rules
- error handling
Pattern 2: Synchronize Tenants and Leases
When to use this pattern
Use this pattern when resident or tenant occupancy data must be aligned with a CRM, finance platform, analytics environment, or resident-facing application. It is particularly useful for effective-dated lease changes and renewals.
Integration direction
Example Mapping
| MRI Software Field | Canonical Field | Target Field |
|---|---|---|
| Tenant.identifier | partyId | External Contact or Customer ID |
| Tenant.email | ||
| Lease.startDate | leaseStartDate | Lease Start Date |
| Lease.endDate | leaseEndDate | Lease End Date |
Martini implementation pattern
Martini retrieves Tenants and Leases through the confirmed MRI API or export path, applies privacy and ownership rules, validates Property and Unit relationships, and maps effective-dated terms to the target model. Duplicate detection uses MRI identifiers and approved business keys; transient failures are retried without creating duplicate contacts or leases.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- validation
- privacy-aware logging
- idempotent upserts
- retry handling
Pattern 3: Orchestrate MRI Work Orders
When to use this pattern
Use this pattern when a resident, facilities, or service-management application needs to submit maintenance requests to MRI and receive status or completion updates. Near-real-time behavior depends on available MRI API operations; otherwise scheduled polling is used.
Integration direction
Example Mapping
| MRI Software Field | Canonical Field | Target Field |
|---|---|---|
| request.externalId | workOrderRequestId | Work Order External ID |
| request.propertyId | propertyId | Property Identifier |
| request.priority | priority | Work Order Priority |
| request.status | workOrderStatus | Work Order Status |
Martini implementation pattern
Martini exposes a controlled API or consumes the originating application's request, validates Property, Unit, Vendor, and priority references, and maps the request to the MRI Work Order model. It stores the resulting MRI identifier, prevents duplicate creates with an idempotency key, and polls or processes provisioned callbacks for status updates.
Martini capabilities used
- API exposure
- workflows
- data mapping
- validation
- business rules
- idempotency
- error handling and retries
Pattern 4: Synchronize Vendors and Work Order Outcomes
When to use this pattern
Use this pattern when MRI property operations must align with an external facilities, procurement, field-service, or finance application. It supports bidirectional synchronization where both systems have confirmed read and write operations.
Integration direction
Example Mapping
| MRI Software Field | Canonical Field | Target Field |
|---|---|---|
| Vendor.identifier | vendorId | Supplier or Vendor External ID |
| Vendor.name | vendorName | Supplier Name |
| WorkOrder.status | serviceStatus | Case or Work Order Status |
| WorkOrder.completedDate | completedAt | Completion Date |
Martini implementation pattern
Martini retrieves Vendors and Work Orders, matches external suppliers using stable identifiers, maps status and completion fields, and applies system-of-record rules to prevent update loops. It records source and target identifiers, retries transient failures, and produces reconciliation results for conflicts or missing relationships.
Martini capabilities used
- workflow orchestration
- API consumption
- data mapping
- business rules
- system-of-record enforcement
- duplicate prevention
- monitoring and reconciliation
Applications commonly integrated with MRI Software
MRI Software commonly participates in broader real-estate, facilities, finance, and enterprise application landscapes. The exact objects and direction should be validated for the selected MRI product, tenant, and target application.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize Properties, Tenants, Leases, and selected engagement information for relationship management and reporting. | MRI Software → Martini → Salesforce | A scheduled Martini workflow retrieves changed MRI objects, maps them to Salesforce accounts, contacts, or custom real-estate objects, applies ownership and privacy rules, and performs idempotent upserts with retry handling. |
| Yardi Voyager | Exchange property, unit, resident, lease, or accounting information when an organization operates both MRI Software and Yardi applications. | MRI Software → Martini → Yardi Voyager | Martini can orchestrate product-specific API or file exchanges, normalize identifiers and effective dates, reconcile Properties, Units, Tenants, and Leases, and route validation failures for review. |
| RealPage | Coordinate resident, property, leasing, or operational information across portfolios using MRI Software and RealPage applications. | MRI Software → Martini → RealPage | A Martini workflow extracts approved MRI data, transforms product-specific fields into a shared real-estate model, sends supported updates to RealPage, and records correlation and reconciliation results. |
| Entrata | Synchronize property, unit, resident, lease, or maintenance information across portfolios using both platforms. | MRI Software → Martini → Entrata | Martini can use scheduled API retrieval or approved file exchange, apply field and status mappings, and use stable MRI identifiers to prevent duplicate resident, lease, or work-order updates. |
| ServiceNow | Send MRI maintenance or facilities Work Orders into service-management workflows and return status or completion updates. | MRI Software → Martini → ServiceNow | Martini exposes an API for intake or polls MRI for changes, maps Work Orders and Vendors to ServiceNow records, applies idempotency and status rules, and synchronizes completion outcomes. |
| Workday | Exchange organizational, supplier, finance, or workforce-related information where MRI operational data must align with enterprise processes. | Workday → Martini → MRI Software | Martini coordinates approved Workday and MRI API operations, validates organization and supplier references, transforms effective-dated data, and isolates product-specific errors from the broader workflow. |
| NetSuite | Synchronize vendors, invoices, payments, or property-related financial information where NetSuite is the financial system of record. | MRI Software → Martini → NetSuite | A scheduled Martini workflow extracts accessible MRI financial objects or files, maps them to NetSuite records, applies accounting and duplicate checks, and writes an auditable reconciliation result. |
| Microsoft Dynamics 365 | Connect property, customer, vendor, or service information with sales, customer-service, or field-service processes. | MRI Software → Martini → Microsoft Dynamics 365 | Martini can normalize MRI payloads, apply routing and ownership rules, invoke Dynamics 365 APIs, and retry transient failures while retaining source identifiers for later synchronization. |
How to build a MRI Software integration in Martini
Objective
Confirm the exact MRI product, tenant, API version, environment, objects, and permissions before configuring the integration.
Instructions in Martini
- Confirm the MRI product, deployment model, API base URL, tenant or organization context, and available objects
- Configure OAuth 2.0, client credentials, API keys, or other confirmed authentication
- Store secrets and refresh tokens in Martini environment configuration or secrets management
- Validate read and write permissions separately for each required object
Objective
Select an event-driven, API-led, scheduled, file-based, or database trigger based on the mechanisms MRI has provisioned.
Instructions in Martini
- Use a Martini API or callback workflow only when MRI or the source application provides the required endpoint
- Use a scheduler for incremental MRI reads when webhooks or callbacks are unavailable
- Define the polling interval, overlap window, and rate-limit policy
- Record the selected trigger and source-of-truth assumptions
Objective
Receive or retrieve MRI data reliably while accounting for product-specific pagination, filters, identifiers, and response formats.
Instructions in Martini
- Retrieve the current resource or process the callback notification
- Handle pagination, modified-date filters, change tokens, versions, or export watermarks where documented
- Capture MRI identifiers, correlation values, and checkpoint information
- Treat attachments and document content as separate transfers unless MRI confirms inline content
Objective
Coordinate validation, enrichment, transformation, target writes, and recovery paths in a maintainable Martini workflow.
Instructions in Martini
- Separate MRI-specific API handling from canonical business processing
- Route records by object type, property, region, or business status when required
- Add validation and quarantine paths for incomplete or invalid relationships
- Use reusable workflow logic for common authentication, paging, mapping, and error handling
Objective
Convert MRI product payloads into stable canonical and target-specific models without spreading MRI schema variation across downstream systems.
Instructions in Martini
- Map Properties, Units, Tenants, Leases, Work Orders, and Vendors using stable identifiers
- Normalize status values, dates, time zones, regional formats, and nullable fields
- Protect personally identifiable and financial information from verbose logs
- Handle custom fields and product-specific schema differences explicitly
Objective
Enforce ownership, deduplication, status, privacy, and lifecycle rules before writing to another system or back to MRI.
Instructions in Martini
- Define the system of record for each object
- Generate deterministic idempotency keys for creates and updates
- Distinguish inactive, archived, deleted, and current objects
- Prevent update loops by recording source and target identifiers
Common MRI Software data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Properties | Represents buildings, communities, or managed real-estate assets used as the top-level context for operational data. | Salesforce, data warehouses, Yardi Voyager, RealPage, Entrata | Martini retrieves or receives product-specific Property payloads, maps identifiers and regional fields to a canonical property model, and performs incremental upserts with reconciliation. |
| Units | Represents rentable or occupiable spaces within a Property, including availability or occupancy-related attributes where exposed. | Salesforce, RealPage, Entrata, analytics platforms | Martini links Units to stable Property identifiers, handles inactive or archived units, normalizes status values, and protects downstream systems from product-specific schemas. |
| Tenants / Residents | Represents people or organizations occupying or leasing Units. | Salesforce, resident platforms, analytics, finance systems | Martini applies privacy controls, deduplicates by approved identifiers, maps contact and occupancy fields, and restricts sensitive values in logs. |
| Leases | Represents agreements connecting Tenants, Units, rent terms, and lease dates. | Salesforce, NetSuite, Yardi Voyager, RealPage, analytics platforms | Martini transforms effective-dated terms, handles amendments and renewals, validates related Property and Unit references, and uses idempotent updates. |
| Work Orders | Represents maintenance or service requests with status, priority, assignment, and completion information. | ServiceNow, facilities platforms, field-service applications, resident platforms | Martini maps MRI statuses, Vendors, properties, units, priorities, and assignments; it exposes or consumes APIs and uses idempotency, retries, and reconciliation. |
| Vendors | Represents external service providers associated with maintenance, procurement, or property operations. | ServiceNow, NetSuite, procurement systems, facilities platforms | Martini matches Vendors using stable identifiers and controlled business keys, validates related Work Orders, and prevents duplicate supplier creation. |
Authentication and security considerations
Product-specific authentication
MRI Software authentication varies by product, tenant, deployment, and API. OAuth 2.0 may apply to newer REST APIs, while selected products or partner APIs may use client credentials or API keys. Confirm the authorization server, grant type, scopes, token lifetime, refresh behavior, and tenant context before implementation.
Credential protection
- Store client secrets, API keys, and refresh tokens in Martini environment configuration or secrets management.
- Use least-privilege MRI roles and API scopes for each workflow.
- Protect resident, tenant, lease, payment, and operational data in transport and logs.
- Separate sandbox and production credentials and configuration.
Operational considerations for MRI Software integrations
API behavior and synchronization
- Confirm MRI-specific rate limits, quotas, concurrency limits, and response headers.
- Handle pagination and use modified timestamps, change tokens, versions, or export watermarks where available.
- Use overlap windows and deduplication when reliable incremental change tracking is unavailable.
- Create deterministic idempotency keys for Work Orders, Tenants, Leases, invoices, and payments.
Schema and file variation
- Expect product-specific fields, custom fields, nullable values, status enumerations, identifiers, and date or timezone differences.
- Validate attachment size, content type, URL expiration, permissions, and duplicate-transfer behavior.
- Do not assume direct database access or a universal attachment endpoint for hosted MRI environments.
Monitoring and reconciliation
Use structured workflow logs and correlation identifiers while excluding tokens and unnecessary personal data. Retry transient failures, quarantine validation errors, and reconcile missing, duplicate, stale, or conflicting objects after scheduled runs.
Why use Martini instead of scripts or point-to-point integrations?
Reusable integration workflows
Martini separates MRI-specific API handling from canonical business logic, allowing product and tenant variations to be isolated in mappings and configuration rather than duplicated across point-to-point scripts.
Controlled orchestration
Workflows can combine authentication, pagination, validation, transformation, business rules, target writes, retries, and reconciliation for scheduled or API-led integrations. Martini can also expose a controlled REST API façade that normalizes MRI data for downstream applications.
Maintainability and operations
- Centralize secrets and environment-specific configuration.
- Reuse mappings and workflow logic across MRI products or properties where appropriate.
- Apply consistent idempotency, error handling, monitoring, and checkpoint strategies.
- Extend workflows with custom logic when product-specific transformations require it.
Frequently asked questions
MRI Software can be integrated through product-specific REST APIs and integration services, with authentication and object coverage confirmed for the selected product and tenant. Depending on the product, scheduled exports, file exchanges, callbacks, or an approved database feed may also be available. Martini can orchestrate these mechanisms, transform MRI data, and synchronize it with enterprise applications.
Yes. Martini can integrate with MRI Software by consuming a confirmed MRI REST API and by processing other MRI-supported mechanisms such as scheduled files, callbacks, or an approved database connection when available. The exact implementation depends on the MRI product, API version, authentication model, and tenant configuration.
No. A dedicated MRI Software connector is not required. Martini can use MRI's confirmed native APIs, authentication methods, scheduled exchanges, files, callbacks, or approved database access, with the specific mechanism validated for the selected MRI product.
Lonti does not charge an additional per-connector or per-vendor fee to integrate MRI Software. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from MRI Software, cloud infrastructure, or other third-party systems depending on subscription, API usage, and deployment model.
Use a confirmed MRI REST API where the selected product exposes the required objects and operations. Use scheduled API reads, exports, or files when event notifications are unavailable. OAuth 2.0, client credentials, API keys, tenant context, and product permissions are product-specific and must be confirmed before implementation. GraphQL is not confirmed, and SOAP should be treated as product-specific or legacy until verified.
Universal webhook support was not confirmed. Some MRI products or partner programs may provide event notifications, callbacks, or integration queues for selected events. If the required callback is provisioned, Martini can receive it and retrieve the authoritative resource; otherwise, scheduled incremental synchronization is the safer design.
Use the documented modified timestamp, change token, version, server-side filter, or export watermark where available. If no reliable change mechanism exists, Martini can use scheduled polling with overlap windows, stable MRI identifiers, and idempotent upserts. Martini mappings can normalize product-specific Properties, Units, Tenants, Leases, Work Orders, and Vendors into canonical and target-specific models.
Martini workflows can classify authentication, validation, throttling, service availability, and downstream errors, then retry transient failures with controlled backoff. Deterministic idempotency keys and stored source identifiers help prevent duplicates. Validation, checkpoints, structured logs, and reconciliation workflows can identify failed pages, stale records, conflicting updates, and schema changes. Martini can also expose a normalized REST API façade for downstream systems when appropriate.
Related Martini documentation
Workflows
Data
Plan your MRI Software integration
Validate the MRI product, tenant, API access, authentication model, objects, and synchronization requirements, then use Martini to implement a secure and maintainable integration workflow.