> ## Documentation Index > Fetch the complete documentation index at: https://docs.loqate.com/llms.txt > Use this file to discover all available pages before exploring further. # Oracle Integration Cloud Integration Guide > Install the GBG Loqate Reach and GBG Loqate Verify adapters from the Oracle Integration Store and configure a connection to verify addresses inside Oracle Integration flows. GBG Loqate publishes two adapters in the Oracle Integration Store. Both bring Loqate address verification into Oracle Integration as a native connector, so you can verify addresses inside an integration flow without writing custom REST calls, handling authentication, or parsing Loqate response codes yourself. This guide covers choosing an adapter, installing it, and configuring a connection. For mapping the action into a flow and working with the response, see the [Usage Guide](https://docs.loqate.com/integrations/oracle-integration-cloud-usage.md). ## Which adapter should you use? | | GBG Loqate Reach | GBG Loqate Verify | | - | - | - | | **What it returns** | Corrected address, standardised components, AVC, a confidence score, and an accept, review, or reject recommendation | Corrected address, standardised components, AVC, and the Address Quality Index | | **Decisioning** | Yes, driven by a verification policy you choose on the connection | No, you apply your own rules to the returned codes | | **Typical use** | Customer onboarding, KYC, checkout, anywhere the flow needs a decision to branch on | Data cleansing, migrations, enrichment, anywhere you already have your own quality rules | | **API key travels as** | An `Authorization: Bearer` header | A field inside the request body | | **Endpoint** | `https://reach-oci.location.gbg.com` | `https://oci.location.gbg.com/Cleansing/International/Batch/v1.2/json6.ws` | Both adapters expose the same action, **Verify address**, and accept the same input. The difference is what comes back. If you want Loqate to make a policy-aware judgement on the address, use Reach. If you want the verification result and nothing more, use Verify. You can install both adapters on the same instance. They are independent connectors with separate connections. ## Installing the adapter The adapters require **Oracle Integration 3** and do not appear on a Generation 2 instance. You need permission to install from the Integration Store and to create connections, normally the **ServiceDeveloper** role or higher. Each adapter calls a single allowlisted host, shown in the table above, so confirm your instance has outbound access to it. **1. Open the Integration Store** Sign in to Oracle Integration and open the **Integration Store**. **2. Find the adapter** Search for `Loqate`, then select **GBG Loqate Reach** or **GBG Loqate Verify**. Both are published by GB Group plc. **3. Install** Click **Get** and accept the Oracle Cloud Marketplace terms of use when prompted. **4. Confirm** When installation finishes, the adapter appears in your **Adapters** list and becomes selectable when you create a connection. > [!NOTE] > > If the adapter does not appear straight away, the Integration Store catalogue cache can take up to eight hours to refresh. An administrator can force a refresh rather than wait. > [!NOTE] > > If your instance already has a privately registered adapter using the same identifier (`1616497:loqate-reach` or `1616497:loqate-verify`), installation fails with **ICS-18541: An error occurred while installing RAB adapter**. Remove the private registration first, then install from the Store. The two cannot coexist, because they claim the same adapter identifier. ## Creating a connection: GBG Loqate Reach 1. In Oracle Integration, go to **Design** > **Connections** and click **Create**. 2. Choose the **GBG Loqate Reach** adapter. 3. Give the connection a name, set the role to **Invoke**, and click **Create**. 4. Complete the connection properties. | Field | Required | Default | Notes | | - | - | - | - | | Loqate MCP endpoint | Yes | `https://reach-oci.location.gbg.com` | Leave the default unless GBG has provided a regional or private endpoint for your account | | Verification policy | Yes | `standard` | Governs the accept, review, and reject thresholds. See [Verification policies](#verification-policies) below | 5. Under **Security**, choose **Loqate API key** and paste your key into the **Loqate API key** field. The adapter applies it as an `Authorization: Bearer` header on every call. 6. Click **Save**, then **Test**, then **Save** again once the test succeeds. ### Verification policies The policy sets how demanding Loqate is before it will recommend accepting an address. | Policy | Intended for | | - | - | | `strict` | KYC and regulated onboarding, where a wrong address carries compliance risk | | `shipping` | Delivery and fulfilment, where the address must be physically deliverable | | `standard` | General purpose use. This is the default | | `permissive` | Early funnel lead capture, where you would rather keep a usable record than reject it | Changing the policy changes only the recommendation, not the verification itself. The AVC and the corrected address are unaffected. These are the same policies used across GBG Reach; see [Policies](https://docs.loqate.com/ai-agents/reference/policies.md) for more detail. ## Creating a connection: GBG Loqate Verify 1. Go to **Design** > **Connections** and click **Create**. 2. Choose the **GBG Loqate Verify** adapter. 3. Give the connection a name, set the role to **Invoke**, and click **Create**. 4. Complete the connection properties. | Field | Required | Default | Notes | | - | - | - | - | | Loqate Verify endpoint | Yes | `https://oci.location.gbg.com/Cleansing/International/Batch/v1.2/json6.ws` | Leave the default unless GBG has provided a regional or private endpoint for your account | | Loqate API key | Yes | None | Stored as a password field and never displayed after saving | 5. Click **Save**, then **Test**, then **Save** again once the test succeeds. > [!NOTE] > > This connection shows **No HTTP authentication** under Security, and that is by design. The Loqate Verify json6 service takes the API key inside the request body rather than in an HTTP header, so the key is supplied through the **Loqate API key** connection property instead. See the [Verify API reference](https://docs.loqate.com/api-reference/address-verify/international-batch-cleanse-oci.md) for the underlying endpoint. The API reference writes the version as `v1.20` rather than the adapter's `v1.2`. Both paths reach the same service, so you can keep the adapter's default. ## Testing the connection Clicking **Test** performs a live call, so a success means your key, endpoint, and network path all work together. | Adapter | What the test does | Success means | | - | - | - | | GBG Loqate Reach | Requests the list of available verification policies | The endpoint returned a valid response and your key was accepted | | GBG Loqate Verify | Verifies a known United States address | The endpoint returned HTTP 200 with at least one result | If the test fails, work through these in order. | Message | Likely cause | What to do | | - | - | - | | Connection test failed, the endpoint did not return a valid Loqate MCP response | Wrong endpoint URL, or outbound traffic blocked | Confirm the endpoint matches the default, and that your instance can reach that host | | Connection test failed, the Loqate Verify endpoint did not return a valid response | Wrong endpoint URL or rejected API key | Check the endpoint path is complete, including `/Cleansing/International/Batch/v1.2/json6.ws` | | Unauthorized (401) | API key missing, mistyped, or not entitled to the service | Confirm the key value is correct and re-enter it | ## Usage attribution Both adapters add a `Source` parameter to every outbound call, identifying Oracle Integration as the calling application in your Loqate usage reporting. Connection tests are tagged separately from live verification calls, so testing a connection does not distort your usage figures. You do not need to configure anything for this, and the value cannot be edited from the connection. ## Next steps > [card] [Usage Guide](https://docs.loqate.com/integrations/oracle-integration-cloud-usage.md) > > Add the Verify address action to a flow, map the request, and work with the response. > [card] [Oracle Cloud Marketplace](https://docs.loqate.com/integrations/oracle-cloud-marketplace.md) > > Deploy Loqate Verify into your own Oracle Cloud Infrastructure tenancy.