MRI Software connector

Difficulty: 🔧ADVANCEDPartnership Required + Custom Composite Credential + Manual Per-Consumer Web Services User Setup
Authentication: Basic AuthHTTP Basic Authentication with an MRI-issued composite credential — not OAuth. There are no scopes and no token expiry.
Webhooks: No webhooks — change detection is polling-based.
Partnership Required: Yes(Yes — an MRI relationship supplies the required MIX Partner Key.)
Partnership Application: myMRI Partner Portal↗
Apideck Credentials: Not available
Costs: No published self-serve API pricing — access and economic terms are negotiated individually with MRI. MIX API licensing may carry a fee.
Sandbox Availability: Not available(None for integration providers — testing runs against a consumer's own MRI installation.)
Account Type Required: An MRI client with Web Services (MIX APIs) licensed on their own MRI installation; the consumer supplies their own installation credentials.
Consumer Access Level: A dedicated MRI Web Services user with a role granting rights to each API in use — a plain client login is not sufficient.
Rate Limits: Partner keys: 1,000 requests per rolling 5-minute window. Developer keys carry a lower, unpublished rate. MRI documents no per-day figure.

Task	You (Customer)	Your Consumer	Apideck
Obtain the MRI integration contract and API key	✓	—	—
Configure the MRI-issued integration key in Apideck integration settings	✓	—	—
Provision a Web Services user with API rights in MRI security administration	—	✓	—
Supply installation credentials (domain, client ID, database name, Web Services username and password)	—	✓	—
Credential storage and API translation	—	—	✓
Change detection and polling for updates	✓	—	—

Testing: MRI provides no general-purpose sandbox to integration providers, so there is no environment you can request for yourself. Testing runs against a consumer's MRI installation — their sandbox environment where one exists, otherwise their production installation.
Production: The consumer's own MRI installation. Requires a dedicated Web Services user with API rights, provisioned by an MRI security administrator.
Both: ⚠️ Credentials are installation-specific and cannot be interchanged: the base URL embeds the installation domain and the credential embeds the client ID and application database name, so a credential set only ever works against the installation it was issued for, and a test installation needs its own separate connection. Where no separate test installation exists, treat every call as touching live property and financial data.

MRI grants API access through its Partner Connect programme or a customer-led introduction — engage MRI early and ask your contact for current onboarding expectations.
The two key tiers are not interchangeable: a Partner key only executes APIs MRI has registered in its manifest, while a Developer key runs ad-hoc APIs. Requesting the wrong tier blocks calls you expect to work.
There is no shared, multi-tenant MRI API host — every connection targets that consumer's own installation at https://{domain}/MRIAPIServices, so every consumer onboards with their own installation hostname.
A 401 from MRI does not identify its own cause, so an authentication failure cannot be self-diagnosed — expect support round-trips with MRI when a connection will not validate.
Public API documentation is minimal and dated — the main openly available reference is MRI's API Design Guide from 2016. Current technical specifics reach you only through the MRI relationship, so you cannot fully scope the build before entering it.

1 gotcha across 1 resource

Connector-specific behaviors and limitations to be aware of

10 supported resources

View field mappings, supported operations, and schema details