# Mercury Network

> Planned: accept orders, update inspection status and upload reports in Mercury Network by text.

Status: Coming soon

Source: https://asktack.com/docs/integrations/mercury-network/

**Status: planned — not available to connect in Tack yet.** These steps prepare the integration; creating vendor credentials does not enable it in the app.

## Planned workflows

Planned for Mercury Network:

| You text | What would happen in Mercury Network |
|---|---|
| "Accept the 18 Cedar order" | Accepts the order |
| "Inspection scheduled for 18 Cedar Friday 10am" | Updates the order status |

These are intended workflows, not a guarantee that every operation is exposed by the vendor. Each must pass the API and permission checks below before release.

## Before you start

This integration requires vendor confirmation. Mercury Network's published [AQM integration material](https://help.mercuryvmp.com/docs/9600.htm) describes appraisal-quality-management services; it does not establish that an individual appraiser can obtain general order-management write access.

## Developer setup — vendor approval first

1. Ask Mercury Network for its approved integration route for the exact use cases: accepting an order, setting an inspection date/status and uploading a report.
2. Request partner eligibility, required agreements, pricing, current API documentation, test access and the production-approval process.
3. Obtain an explicit list of permitted read/write operations and authentication instructions. Confirm whether access is scoped to an appraiser, appraisal firm, lender or AMC.
4. Build only against the approved interface. AQM credentials must not be assumed to authorize order management. A browser-password connection is not an established fallback.

## Customer setup — after a route is approved

1. Identify the customer's Mercury account type and the lender/AMC relationships involved.
2. Have the authorized account owner request enablement for the approved partner integration.
3. Follow the vendor-issued authorization or credential steps and store credentials through the secure setup process.
4. Record account/firm identifiers, allowed clients and allowed status transitions. Obtain a test order designated by the customer and vendor.
5. Have an operator confirm which actions need human acceptance and which uploads constitute final delivery.

## Verify write access

Start with a read of the designated test order. Exercise an explicitly permitted, reversible status update and verify it with the operator. Test document upload only against a non-delivery test path confirmed by Mercury. Record audit attribution and duplicate-request handling before enabling any order acceptance or final delivery.

## Disconnect and unresolved details

Require Mercury to document how the customer revokes the partner grant or disables credentials. Test that procedure before launch and remove local secrets. Exact account menus, authorization fields and available order-write endpoints remain unconfirmed; obtaining that information is the next required step, not a task a customer can complete by guessing settings.

## Who completes the work?

An agent/developer can implement the connector, field mappings and automated checks. A customer administrator must authorize account access and permissions; the vendor must approve any restricted partner access. A business operator verifies the test records before production use. Follow the [shared setup and release checklist](https://asktack.com/docs/integration-setup/) for credential handling, approval gates and launch checks.

_Setup guidance reviewed October 23, 2026. Vendor menus and entitlements can change; unresolved details are called out above._