Troubleshooting a 403 Forbidden in the Reltio MDM (RIH/Workato) Connector

Problem

A 403 Forbidden response from the Reltio MDM connector usually indicates that authorization is failing (roles/permissions) or that the request is being blocked by an IP allowlist on the tenant. This article provides a practical triage flow to isolate and fix the issue.

Symptoms

You see a 403 Forbidden when running a recipe/action using the Reltio MDM connector (RIH/Workato). Common examples:

• Connection test fails with 403

• A specific action (search/create/update) fails with 403

• DEV works, but TEST/QA fails with 403

Triage Flow 

Verify Connector Connection Fields (RIH UI)

Open the connector connection settings and confirm:

• Environment URL: Use the correct short alias/environment endpoint expected for that tenant.

• Tenant ID: Must be the correct 22-character tenant ID.

• Use Client Authorization: Yes

• Client ID / Secret: Must match the intended application's client ID and secret.

• Use Custom Authorization Service: Leave blank (unless you are intentionally using internal/custom auth)

If you are comparing DEV vs TEST, do not rely on exported connection packages (see section below). Use UI screenshots/values.

Token Sanity Check (Credentials Only)

This step confirms your Client ID/Secret is valid, independent of the connector configuration.

In Postman:

• Request an access token using client_credentials for the same client used in the connector.

Interpretation

• Token request succeeds → credentials are valid; move to authorization + allowlist checks.

• Token request fails → fix client ID/secret or token endpoint mismatch before anything else.

Client → Tenant Role Mapping (Authorization)

Even with a valid token, you can still get 403 if the client lacks the right tenant roles.

In Reltio Console:

• Go to Client Credentials

• Open the application client

• Verify the target tenant (e.g., QA/TEST) is listed and has the expected roles (examples you might see):

  • ROLE_API

  • ROLE_INTEGRATION_CUSTOMER_ADMIN

  • etc.

Interpretation

• Roles missing for the tenant → add roles, then retest.

• Roles present → proceed to allowlist check.

Don’t Trust Connection Exports for Diffing

Connection export packages are incomplete for troubleshooting:

• They include names/providers only

• They exclude field values and secrets (the stuff that most often causes 403s)

Best practice

• Compare RIH UI connection settings side-by-side (screenshots or manual review) when diffing DEV vs TEST.

Check Tenant IP Allowlisting (Most Common DEV-vs-TEST Cause)

A frequent reason DEV works but TEST fails:

• IP allowlists are tenant-scoped

• DEV and TEST tenants enforce separate allowlists

• RIH/Workato egress IPs are region / data-center / sub-account based (they can differ between workspaces)

What to do

1. Determine whether the tenant has IP allowlisting enabled.

2. If enabled, confirm the RIH/Workato egress IPs for your TEST workspace/region are added to that tenant’s allowlist.

Interpretation

• DEV tenant allowlist includes its RIH IPs → DEV works

• TEST tenant allowlist missing TEST workspace IPs → TEST fails with 403

Special Note: “Use of Custom Authorization Service”

In the RIH Reltio MDM connector, the behavior is:

• Yes
  Routes authentication through an internal/custom auth service (typically for internal Reltio environments like QA/DEV) and requires selecting the matching internal Environment.

• No (or left blank)
  Uses the standard customer-facing Reltio auth flow based on:

  • Environment URL

  • Tenant ID

  • Client credentials (or user credentials)

Important

• If the field is left blank, it is treated the same as No.

• For customer tenants (normal prod/non-internal): leave it blank.

• Only set it to Yes when you intentionally need the internal/custom auth path.

Quick Decision Guide

• Token request fails in Postman → credential/config issue (client id/secret or token endpoint).

• Token succeeds, but connector still 403s → most likely:

  • Missing tenant roles for the client or

  • Tenant IP allowlist blocking the RIH/Workato egress IPs

Resolution Checklist

• Confirm Environment URL alias + Tenant ID (22 chars)

• Use Client Authorization = Yes

• Validate token via Postman (client_credentials)

• Verify client has roles on the target tenant in Console

• If allowlisting is enabled: add correct RIH/Workato egress IPs for the workspace/region/sub-account

• Ensure “Use Custom Authorization Service” is blank unless intentionally required

Escalation Data to Collect

If you still see a 403 after the steps above, capture:

• Tenant ID and environment alias

• Which workspace/region/sub-account does the recipe run in

• Confirmation whether tenant allowlisting is enabled

• The exact action endpoint failing (and timestamp)

• Client ID and confirmed tenant role list

• Postman token request result (success + token audience/issuer if available)