# RUI IVASS Insurance Intermediaries (`beyondforge/rui-ivass-insurance-intermediaries`) Actor

Search, verify, export and monitor the RUI IVASS register of Italian insurance intermediaries. Batch-check RUI numbers, build full profiles, export relationships, mandates, offices and websites, and detect registry changes from official IVASS open data.

- **URL**: https://apify.com/beyondforge/rui-ivass-insurance-intermediaries.md
- **Developed by:** [Dario Mattioli](https://apify.com/beyondforge) (community)
- **Categories:** Automation, Developer tools, Lead generation
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $0.50 / 1,000 search results

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## RUI IVASS Insurance Intermediaries — Registro RUI Search, Verification & Monitoring

Search, verify, export, enrich, and monitor the **RUI IVASS** public register of Italian insurance intermediaries using structured data from the official IVASS open-data source.

This Actor turns the **IVASS RUI** register into API-ready datasets for **ricerca RUI**, **iscritti RUI**, **registro RUI**, batch verification, full intermediary profiles, relationships, mandates, offices, websites, and change monitoring.

If you need to consult the **Registro Unico Intermediari**, verify a **numero iscrizione RUI**, build an **elenco iscritti RUI**, or integrate the Italian insurance intermediary register into an automated workflow, this Actor provides structured results instead of requiring manual lookups one at a time.

### What you can do

The Actor supports five operations:

| Operation                | Purpose                                                                   |
| ------------------------ | ------------------------------------------------------------------------- |
| **Search & bulk export** | Search and filter intermediaries across the RUI and EU Annex              |
| **Batch verify**         | Check RUI numbers, person/company names, or websites/domains              |
| **Full profile**         | Build joined intermediary profiles from multiple IVASS datasets           |
| **Relationships export** | Export collaborators, mandates, offices, websites, roles, and other links |
| **Changes & monitoring** | Detect changes between successive IVASS registry snapshots                |

All delivered results are written to the run's default Apify Dataset and can be exported or consumed through the Apify API.

***

### Why use this Actor?

The public IVASS RUI portal is useful for individual consultation. This Actor is designed for workflows that need structured, repeatable, or bulk access.

Typical advantages include:

- bulk **RUI IVASS search**
- structured JSON output
- batch **RUI verification**
- RUI number normalization
- person/company lookup
- operational-status filtering
- filtering by RUI section
- regional and provincial filtering
- insurance-company mandate filtering
- website/domain lookup
- EU Annex filtering
- full profiles joined across IVASS datasets
- collaborator networks
- mandates
- offices
- websites
- corporate roles
- linked-intermediary enrichment
- persistent change monitoring
- data-quality metadata
- source and snapshot metadata
- API and automation-ready output

Typical users and workflows include:

- insurance compliance
- due diligence
- intermediary onboarding
- broker and agent verification
- insurance intelligence
- CRM enrichment
- data pipelines
- registry monitoring
- audit workflows
- AI agents requiring structured Italian insurance-register data

***

## RUI IVASS search

Use **Search & bulk export** for a general **ricerca RUI** or to build a filtered list of **iscritti RUI**.

You can search by person/company name or leave the name empty and use filters only.

### Available Search filters

- name or company name
- RUI section
- entity type
- operational status
- Italian region
- province
- insurance company / mandate
- website availability
- registration date range
- EU activity regime
- maximum number of results

Supported register sections:

- A
- B
- C
- D
- E
- F
- EU Annex

Province filters accept either the province name or abbreviation.

For example:

```text
Roma
RM
```

When region and province are supplied together, they must match compatible geographic information from the same office record.

### Search example

```json
{
  "mode": "search",
  "nameQuery": "ROSSI",
  "sections": ["A", "B"],
  "entityType": "person",
  "operationalStatus": "operational",
  "regions": ["Lombardia"],
  "provinces": ["MI"],
  "hasWebsite": "any",
  "maxResults": 100,
  "includeDataQuality": true,
  "includeSourceMetadata": true
}
```

### Search output

Search produces records with:

```json
{
  "recordType": "intermediary",
  "ruiNumber": "E000123456",
  "section": "E",
  "entityType": "person",
  "operational": true,
  "registrationDate": "2025-01-28",
  "person": {},
  "company": null,
  "counts": {},
  "dataQuality": {},
  "source": {}
}
```

The values above illustrate the output structure and are not intended to represent a guaranteed current RUI record.

***

## Batch RUI verification

Use **Batch verify** when you already have values that need to be checked against the current IVASS registry.

Supported verification methods:

1. **RUI number**
2. **Person or company name**
3. **Website or domain**

Multiple values can be checked in one run.

### Verify a numero iscrizione RUI

```json
{
  "mode": "verify",
  "verificationType": "rui_number",
  "verificationValues": [
    "E000769268",
    "E000-745304"
  ]
}
```

User-supplied RUI numbers are normalized for matching without rewriting the underlying source records.

Possible match statuses include:

```text
exact_unique
exact_multiple
partial
not_found
invalid_input
```

If a RUI number is associated with multiple source records, the Actor does not arbitrarily select one of them.

Instead, it reports the ambiguity.

### Verify by name

```json
{
  "mode": "verify",
  "verificationType": "name",
  "verificationValues": [
    "ROSSI MARIO"
  ],
  "nameMatchMode": "exact_then_partial"
}
```

Available matching modes:

```text
exact_only
exact_then_partial
```

When enabled, partial candidates can be returned when an appropriate exact match is not available.

### Verify website or domain

```json
{
  "mode": "verify",
  "verificationType": "domain",
  "verificationValues": [
    "example.it"
  ]
}
```

A website or domain may be connected to more than one intermediary.

This is particularly relevant for insurance networks using shared domains or subdomains.

The Actor preserves the distinct intermediary matches instead of assuming that a shared website belongs to only one RUI record.

### Verification output

```json
{
  "recordType": "verification",
  "verificationType": "rui_number",
  "inputValue": "E000769268",
  "normalizedInput": "E000769268",
  "matchStatus": "exact_unique",
  "matchCount": 1,
  "matches": [],
  "dataQuality": {},
  "source": {}
}
```

***

## Full intermediary profiles

Use **Full profile** when you want more than a basic **registro RUI** lookup.

This operation joins the selected RUI number with compatible information from the other IVASS datasets.

Depending on the intermediary and available source data, a profile can include:

- intermediary identity
- registration information
- operational status
- EU Annex information
- offices
- websites
- insurance-company mandates
- corporate roles
- first-level collaborations
- second-level collaborations
- accessory intermediary records
- Section D distribution responsibles
- non-standard product agents
- data-quality metadata
- source metadata

### Full Profile example

```json
{
  "mode": "full_profile",
  "profileRuiNumbers": [
    "UE00010496"
  ],
  "includeCollaboratorsInProfile": false,
  "includeDataQuality": true,
  "includeSourceMetadata": true
}
```

### Embedding collaborators

To include complete collaborator relationships inside a profile:

```json
{
  "includeCollaboratorsInProfile": true
}
```

Some intermediary networks can contain thousands of collaboration records.

For large networks, **Relationships export** is generally preferable because relationships are returned as individual Dataset items instead of creating one very large profile.

A payload-safety guard is also applied to unusually large Full Profile results.

***

## RUI relationships export

Use **Relationships export** to extract individual relationships from the IVASS datasets.

Supported relationship types are:

```text
collaborations
accessory_intermediaries
offices
websites
mandates
corporate_roles
section_d_responsibles
non_standard_product_agents
```

You can limit results to selected RUI numbers or export compatible relationships across the registry.

Both first- and second-level collaborations are supported.

### Relationships example

```json
{
  "mode": "relationships",
  "relationshipTypes": [
    "collaborations",
    "mandates",
    "websites"
  ],
  "relationshipRuiNumbers": [
    "A000006378"
  ],
  "collaborationLevels": [
    "1",
    "2"
  ],
  "includeLinkedIntermediaryDetails": true,
  "maxResults": 100,
  "includeDataQuality": true,
  "includeSourceMetadata": true
}
```

### Linked intermediary enrichment

With:

```json
{
  "includeLinkedIntermediaryDetails": true
}
```

the Actor attempts to add current identity and status information for RUI numbers referenced by the relationship.

If a referenced RUI number cannot be found in the current intermediary dataset, it is not silently discarded.

The condition can instead be reported through `dataQuality`.

Duplicate linked RUI situations are also preserved rather than arbitrarily resolved.

### Relationship output

```json
{
  "recordType": "relationship",
  "relationshipType": "collaborations",
  "sourceTable": "ELENCO_COLLABORATORI.csv",
  "ruiNumbers": [],
  "matchedFilterRuiNumbers": [],
  "relationship": {},
  "linkedIntermediaries": [],
  "dataQuality": {},
  "source": {}
}
```

***

## Changes & RUI monitoring

Use **Changes & monitoring** when you need to know what changed in the IVASS RUI register between snapshots.

The Actor maintains a persistent baseline and compares a new valid registry snapshot against the previous baseline.

Supported change types:

```text
INTERMEDIARY_ADDED
INTERMEDIARY_REMOVED
STATUS_CHANGED
WEBSITE_ADDED
WEBSITE_REMOVED
OFFICE_ADDED
OFFICE_REMOVED
MANDATE_ADDED
MANDATE_REMOVED
COLLABORATOR_ADDED
COLLABORATOR_REMOVED
ROLE_ADDED
ROLE_REMOVED
RESPONSIBLE_D_CHANGED
```

### Monitoring example

```json
{
  "mode": "changes",
  "changeTypes": [
    "INTERMEDIARY_ADDED",
    "INTERMEDIARY_REMOVED",
    "STATUS_CHANGED"
  ],
  "historyNamespace": "my-monitor",
  "updateBaseline": true,
  "maxResults": 100,
  "includeDataQuality": true,
  "includeSourceMetadata": true
}
```

### How the monitoring baseline works

For a new `historyNamespace`:

1. the first successful run initializes the baseline
2. no historical changes are invented before that baseline
3. a later run compares the current valid IVASS snapshot with the stored baseline
4. detected differences are returned as `change` records
5. if `updateBaseline` is enabled, the current snapshot becomes the new baseline

### Independent monitoring histories

Different namespaces can maintain independent monitoring histories.

For example:

```text
compliance-team
broker-network-a
daily-monitor
```

Use the same namespace across successive runs when those runs should belong to the same monitoring history.

***

## Official IVASS source

The Actor processes the public open-data export made available by **IVASS — Istituto per la Vigilanza sulle Assicurazioni**.

At the beginning of a run, the Actor downloads the current available RUI archive and validates the expected source structure before producing results.

The source currently contains data used for:

- intermediaries
- collaborators
- accessory intermediaries
- mandates
- offices
- websites
- corporate roles
- Section D distribution responsibles
- non-standard product agents

The Actor does not depend on undocumented private APIs for its core registry dataset.

Where enabled, output records include metadata such as:

```json
{
  "source": {
    "provider": "IVASS",
    "dataset": "RUI",
    "snapshotDate": "2026-08-19",
    "retrievedAt": "2026-08-19T20:39:29Z",
    "sourceUrl": "https://ruipubblico.ivass.it/inquiry-public-manager/inquiry-public/esporta-registro"
  }
}
```

The date above is an example.

Actual results contain metadata for the source snapshot processed by that run.

***

## Dataset output

All delivered results are stored in the default Apify Dataset.

The Actor provides five Dataset views:

| Operation     | Dataset view             | `recordType`   |
| ------------- | ------------------------ | -------------- |
| Search        | **Search results**       | `intermediary` |
| Batch verify  | **Verification results** | `verification` |
| Full profile  | **Full profiles**        | `full_profile` |
| Relationships | **Relationships**        | `relationship` |
| Changes       | **Registry changes**     | `change`       |

Because all five operations share one Dataset schema, Apify may initially display the first configured view, **Search results**.

If you ran a different operation, switch to its corresponding view.

The complete raw record is also available through **All fields**, JSON output, exports, and the Dataset API.

***

## Data quality and ambiguity handling

Public registry data can contain anomalies such as:

- duplicate RUI numbers
- ambiguous names
- malformed source rows
- unusual dates
- references to RUI numbers not present in the primary intermediary dataset

The Actor follows a conservative rule:

> Preserve the source whenever possible, do not invent missing information, and report ambiguity instead of silently resolving it.

Depending on the operation, `dataQuality` can identify conditions such as:

- duplicate RUI numbers
- multiple exact matches
- input normalization
- recovered malformed rows
- suspicious dates
- orphan RUI references
- duplicate linked references
- ambiguous name matches

The Actor validates the archive and expected CSV headers before processing.

If the upstream IVASS structure changes incompatibly, failing clearly is preferable to silently returning unreliable data.

***

## Pay Per Event pricing

This Actor uses **Pay Per Event (PPE)** pricing.

Current configured prices are:

| Event               |                                  Price |
| ------------------- | -------------------------------------: |
| Actor Start         |                        **$0.03 / run** |
| Search result       |         **$0.0005 / delivered result** |
| Verification result | **$0.001 / verification billing unit** |
| Full profile        |          **$0.01 / delivered profile** |
| Relationship result |   **$0.0005 / delivered relationship** |
| Change result       |          **$0.002 / delivered change** |

Always check the current Pricing section on the Actor page before running it, as published pricing may change in the future.

### Cost examples

#### 100 Search results

```text
Actor Start                 $0.030
100 × Search result         $0.050
---------------------------------
Total                       $0.080
```

#### 1 Full Profile

```text
Actor Start                 $0.030
1 × Full profile            $0.010
---------------------------------
Total                       $0.040
```

#### 100 Relationships

```text
Actor Start                 $0.030
100 × Relationship result   $0.050
---------------------------------
Total                       $0.080
```

#### 10 detected changes

```text
Actor Start                 $0.030
10 × Change result          $0.020
---------------------------------
Total                       $0.050
```

***

## Batch Verify billing

Verification billing is based on intermediary matches actually delivered.

For example:

```text
1 intermediary match   → 1 verification billing unit
2 intermediary matches → 2 verification billing units
10 matches             → 10 verification billing units
```

A delivered `not_found` verification uses a minimum of one billing unit.

This matters for shared websites and domains.

A domain used by hundreds of intermediaries can produce hundreds of intermediary matches and is therefore not billed as one inexpensive lookup while delivering hundreds of matching entities.

Billing is based on delivered intermediary matches rather than the number of underlying technical website rows.

***

## Maximum cost per run

Apify's **Maximum cost per run** setting can be used to cap spending.

The Actor checks the remaining Pay Per Event budget before delivering a chargeable result.

For multi-match verification results, delivery is atomic:

- a result is not partially delivered
- individual matches are not cut off simply to fit the remaining budget
- if the remaining run budget cannot cover the complete verification result, that result is skipped
- the verification event is not charged for a result that was not delivered

This is particularly useful for domain verification, where a shared domain may unexpectedly match a large number of intermediaries.

***

## `maxResults`

`maxResults` controls the maximum number of Dataset items returned where applicable.

It applies to:

- Search
- Relationships
- Changes

Example:

```json
{
  "maxResults": 100
}
```

Set:

```json
{
  "maxResults": 0
}
```

to request all matching results.

Larger outputs can increase Pay Per Event charges.

`maxResults` does not replace source validation: the Actor still processes and validates the current registry source before delivering matching output.

Batch Verify and Full Profile are primarily controlled by their dedicated input lists.

***

## RUI API and automation

The Actor can be run manually from Apify Console or integrated into automated workflows.

Typical uses include:

- **RUI IVASS API** workflows
- **IVASS RUI search** integrations
- RUI number checker
- intermediary verification
- scheduled registry checks
- CRM enrichment
- insurance intermediary onboarding
- compliance pipelines
- ETL jobs
- Make integrations
- Zapier integrations
- AI-agent tools
- structured insurance-register datasets

### Python API example

```python
from apify_client import ApifyClient

client = ApifyClient("<APIFY_API_TOKEN>")

run = client.actor(
    "beyondforge/rui-ivass-insurance-intermediaries"
).call(
    run_input={
        "mode": "verify",
        "verificationType": "rui_number",
        "verificationValues": [
            "E000769268"
        ],
        "includeDataQuality": True,
        "includeSourceMetadata": True
    }
)

items = client.dataset(
    run["defaultDatasetId"]
).list_items().items

for item in items:
    print(item)
```

You can also use the **API** button in Apify Console to generate API request examples.

***

## AI agent discovery

The Actor exposes explicit operation names, predictable Dataset record types, and structured results suitable for automated tools and AI agents.

It can be used when an agent needs to:

- search the Italian insurance intermediary register
- perform a RUI register search
- check a RUI number
- verify whether a name appears in the current RUI data
- perform insurance intermediary verification
- inspect website/domain associations
- distinguish unique, multiple, partial, and missing matches
- retrieve complete intermediary profiles
- inspect insurance distribution relationships
- monitor registry changes
- consume source and data-quality metadata

Relevant concepts include:

```text
RUI IVASS
IVASS RUI
Italian insurance intermediary register
RUI register search
RUI number checker
insurance intermediary checker
insurance intermediary verification
registered insurance intermediary lookup
Italian insurance register API
RUI API
RUI monitoring
insurance compliance data
```

***

## Common use cases

### Cerca iscritti RUI

Use Search to find persons or companies in the current register by name or filters.

It can also be used to build a targeted **elenco iscritti RUI** instead of checking records manually one at a time.

### Registro RUI / Registro Unico Intermediari

Use Search & bulk export to query the register using structured filters and retrieve machine-readable output.

### Verifica iscrizione RUI

Use Batch Verify with `verificationType = rui_number` to check one or more registration numbers against the current source snapshot.

### Numero iscrizione RUI checker

Submit known RUI numbers in bulk and receive a structured match status for each supplied value.

### Insurance intermediary checker

Use Batch Verify by RUI number, name, or domain to identify matching intermediary records.

### Broker and agent due diligence

Use registration information together with current operational status, source metadata, mandates, websites, and relationships.

### CRM enrichment

Add RUI data, websites, offices, mandates, and related information to an existing CRM or business dataset.

### Website/domain verification

Check whether a domain appears in the IVASS website dataset and identify the RUI intermediaries associated with it.

### Insurance intelligence

Build structured datasets of intermediaries, relationships, mandates, websites, offices, and related insurance-distribution information.

### RUI change monitoring

Detect intermediary additions or removals, operational-status changes, and changes to websites, offices, mandates, collaborators, roles, and Section D responsibles.

***

## FAQ

### What is RUI IVASS?

RUI is the Italian register used by IVASS for insurance-intermediary information.

This Actor processes the public IVASS RUI open-data source and converts it into structured Dataset records.

### Is “IVASS RUI” the same register?

Users commonly search for the register using terms such as **RUI IVASS**, **IVASS RUI**, **registro RUI**, and **registro IVASS**.

This Actor is specifically designed around the public IVASS RUI data source.

### Can I perform a ricerca RUI by name?

Yes.

Select **Search & bulk export** and enter a person or company name.

You can combine the name with filters such as section, operational status, region, province, mandate, website availability, registration dates, or EU activity regime.

### Can I get an elenco iscritti RUI?

Yes.

Leave the name empty and use Search filters to build a targeted set of intermediaries.

Set an appropriate `maxResults` value according to the size of the export you need.

### Can I verify an iscrizione RUI?

Yes.

Use **Batch verify** with:

```text
Verification type: RUI number
```

and provide one or more registration numbers.

### Can I check a numero iscrizione RUI?

Yes.

The supplied number is normalized for matching, and the result reports whether there is a unique match, multiple matches, or no match in the current source snapshot.

### Can I search the registro intermediari assicurativi by region or province?

Yes, where compatible office/location information is available in the IVASS source data.

Both Italian region and province filters are supported.

### Can I search by insurance company?

Search can filter intermediaries using insurance-company names or codes represented in the mandates dataset.

### Can I verify a broker or insurance agent?

The Actor can search and verify intermediary records present in the IVASS source.

It does not independently issue an authorization or regulatory certification.

### Can I verify an insurance website?

You can use Batch Verify with `verificationType = domain`.

The Actor checks the domain against website information contained in the IVASS dataset and returns the distinct linked intermediary matches.

### Can one domain match many RUI intermediaries?

Yes.

Insurance groups and networks may use a shared domain or subdomain across many intermediaries.

The Actor preserves all distinct matched intermediaries.

### Can one RUI number have multiple records?

Yes, duplicate RUI-number situations can exist in the source.

The Actor reports these as multiple matches instead of choosing one source record arbitrarily.

### Does the Actor support EU intermediaries?

Yes.

Search supports the **EU Annex** as well as EU activity regimes represented in the source data.

### Can I export the results?

Yes.

Results are stored in the default Apify Dataset and can be retrieved through Apify exports, API calls, or integrations.

### Why did my first Changes & monitoring run return no changes?

A new monitoring namespace has no previous baseline.

The first successful run initializes that baseline.

Later runs can detect differences between the stored baseline and newer valid IVASS snapshots.

### Does monitoring provide the complete historical RUI archive?

No.

Changes & monitoring detects changes from the stored baseline forward.

It does not reconstruct historical changes from periods before the baseline existed.

### Which Dataset view should I use?

Use the view corresponding to the selected operation:

```text
Search            → Search results
Batch verify      → Verification results
Full profile      → Full profiles
Relationships     → Relationships
Changes           → Registry changes
```

If Apify initially opens **Search results** after another operation, switch manually to the corresponding view.

***

## Important limitations and disclaimer

### Independent tool

This Actor is an independent data-processing product.

It is **not IVASS**, is not affiliated with IVASS, and does not issue official registrations, certificates, authorizations, regulatory decisions, or legal opinions.

For authoritative regulatory or legal decisions, consult IVASS and the applicable regulations directly.

### Source freshness

Results reflect the IVASS source snapshot available when the run downloads the registry archive.

Source metadata can be included so that downstream systems know which snapshot produced the result.

### No invented corrections

The Actor does not silently rewrite ambiguous or duplicate source information.

When a condition can be identified reliably, it is reported through match status or `dataQuality`.

### Missing related data

Not every intermediary has every relationship type.

A record can legitimately have no:

- website
- mandate
- office matching a particular geography
- corporate role
- collaboration
- accessory record

The absence of one of these related records does not by itself mean that the intermediary record is invalid.

### Monitoring is baseline-based

Change monitoring begins when a baseline is created for a namespace.

It is not a substitute for a complete historical archive of the register.

***

## Reliability and responsible processing

The Actor is designed around deterministic and transparent processing.

Core principles include:

- use the public IVASS open-data registry source
- validate the downloaded archive
- validate expected CSV structure
- avoid inventing missing values
- preserve ambiguous and duplicate source conditions
- normalize user inputs without rewriting source records
- expose data-quality information
- include source and snapshot metadata when requested
- charge Pay Per Event only for results actually delivered
- respect Maximum cost per run before delivery
- avoid partial multi-match verification delivery

***

## Support

If you encounter an unexpected result, open an issue on the Actor page.

For faster troubleshooting, include:

- selected Operation
- relevant input values
- Apify Run ID
- expected behavior
- actual result

Do not publish API tokens, credentials, or other secrets in an issue.

***

## Built for structured RUI data

**RUI IVASS Insurance Intermediaries** is built for users who need more than a manual RUI consultation.

Use it for **RUI IVASS search**, **IVASS RUI verification**, **iscritti RUI**, **registro RUI** exports, **ricerca RUI**, RUI number checking, full profiles, relationship data, change monitoring, APIs, automation, compliance workflows, and machine-readable Italian insurance-intermediary data.

# Actor input Schema

## `mode` (type: `string`):

Choose what this run should do.

## `nameQuery` (type: `string`):

Search mode only. Match a person's name or a company name. Leave empty to search only by filters.

## `sections` (type: `array`):

Search mode only. Limit results to one or more RUI sections. Leave empty for all sections and the EU Annex.

## `entityType` (type: `string`):

Search mode only. Filter persons or companies.

## `operationalStatus` (type: `string`):

Search mode only. Filter by the operational status published in the current IVASS data.

## `regions` (type: `array`):

Search mode only. Filter using available office/location data. Records without compatible geographic data will not be inferred.

## `provinces` (type: `array`):

Search mode only. Enter province names or abbreviations. Geography is applied only where the source provides compatible office/location data.

## `insuranceCompanies` (type: `array`):

Search mode only. Return intermediaries linked to any of these insurance-company names or codes in the mandates dataset.

## `hasWebsite` (type: `string`):

Search mode only. Filter by whether at least one website or URL is present in the IVASS website dataset.

## `registrationDateFrom` (type: `string`):

Search mode only. Earliest registration date, inclusive.

## `registrationDateTo` (type: `string`):

Search mode only. Latest registration date, inclusive.

## `activityRegimes` (type: `array`):

Search mode only. Optional filter for EU Annex intermediaries.

## `verificationType` (type: `string`):

Verify mode only. Choose what the supplied values represent.

## `verificationValues` (type: `array`):

Verify mode only. Enter RUI numbers, names, or domains according to Verification type.

## `nameMatchMode` (type: `string`):

Verify mode with names only. Exact then partial returns exact matches first and partial candidates when no unique exact match exists.

## `profileRuiNumbers` (type: `array`):

Full profile mode only. Enter one or more RUI numbers for which complete joined profiles should be built.

## `includeCollaboratorsInProfile` (type: `boolean`):

Full profile mode only. If enabled, include complete collaborator relationships inside each profile when technically safe. The complete relationships export remains available separately.

## `relationshipTypes` (type: `array`):

Relationships mode only. Leave empty to export all supported relationship types.

## `relationshipRuiNumbers` (type: `array`):

Relationships mode only. Optional list of principal RUI numbers. Leave empty to export relationships across the registry.

## `collaborationLevels` (type: `array`):

Relationships mode only. Filter collaboration records by level. Leave empty for both levels.

## `includeLinkedIntermediaryDetails` (type: `boolean`):

Relationships mode only. Add available intermediary identity and status details to linked RUI numbers.

## `changeTypes` (type: `array`):

Changes mode only. Leave empty to return all detected change types.

## `changeRuiNumbers` (type: `array`):

Changes mode only. Optional list of RUI numbers to filter emitted change records.

## `historyNamespace` (type: `string`):

Changes mode only. Advanced: use a separate name to maintain an independent monitoring baseline. Keep the default unless you need multiple histories.

## `updateBaseline` (type: `boolean`):

Changes mode only. Save the current valid snapshot as the new baseline after comparison.

## `maxResults` (type: `integer`):

Maximum Dataset items for Search, Relationships, or Changes. Use 0 for all matching results. Does not truncate source parsing or validation.

## `includeDataQuality` (type: `boolean`):

Include source warnings such as duplicate RUI numbers, recovered malformed rows, suspicious dates, orphan references, or ambiguous matches.

## `includeSourceMetadata` (type: `boolean`):

Include IVASS source, snapshot date, and retrieval timestamp in output records.

## Actor input object example

```json
{
  "mode": "search",
  "entityType": "all",
  "operationalStatus": "all",
  "hasWebsite": "any",
  "verificationType": "rui_number",
  "nameMatchMode": "exact_then_partial",
  "includeCollaboratorsInProfile": false,
  "includeLinkedIntermediaryDetails": true,
  "historyNamespace": "default",
  "updateBaseline": true,
  "maxResults": 1000,
  "includeDataQuality": true,
  "includeSourceMetadata": true
}
```

# Actor output Schema

## `results` (type: `string`):

Structured result records written to the run's default dataset. The record shape depends on the selected operation.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {};

// Run the Actor and wait for it to finish
const run = await client.actor("beyondforge/rui-ivass-insurance-intermediaries").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {}

# Run the Actor and wait for it to finish
run = client.actor("beyondforge/rui-ivass-insurance-intermediaries").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{}' |
apify call beyondforge/rui-ivass-insurance-intermediaries --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,beyondforge/rui-ivass-insurance-intermediaries"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/y7DnqhUIq7jknpm2v/builds/XnNAs2eq8uUJpHVE8/openapi.json
