SupportExecute a reviewed operation
Execute a reviewed contact-profile read after fetching and validating its current contract.
- Scope
- contacts.readonly
- Authentication
- Bearer private integration
- Token type
- Sub-account token
Execute a supported direct-read operation with validated arguments, understand approval-required failures for mutations, and keep tenant, credential, transport, and server authority out of the request body.
How this fits into Lead360Explore the Lead360 platformConnect API and MCP access with the agency, tenant, scope, and risk model.- 01
Execute only after contract inspection
- 02
Arguments contract
- 03
Direct reads and approval-required changes
- 04
MCP execution
Execute only after contract inspection
- Search operations with the current token and select a returned operation key.
- Fetch the operation contract and confirm execution_mode is direct_read.
- Compare technical scope IDs with the approved integration scope record.
- Validate arguments against required, optional, type, and additionalProperties rules.
- Send POST /operations/{operation_key}/execute with an arguments object.
- Verify the returned operation key, location, execution mode, and result shape.
- Apply data minimization, retention, and redaction requirements to the result.
Arguments contract
The request body contains one arguments object with no more than 64 fields. Lead360 rejects missing required arguments, unexpected fields, invalid basic types, and an arguments value that is not an object. The exact allowed fields come from the fetched operation contract.
Never send location, tenant, sub-account, account, agency, profile, key, authorization, credential, password, secret, token, endpoint, URL, method, headers, database, or SQL authority fields. The server rejects these values because the client must not choose its own security boundary or transport target.
Direct reads and approval-required changes
| Execution mode | Behavior | Client response |
|---|---|---|
| direct_read | Runs a reviewed tenant-aware read adapter | Process only the minimum result required by the integration purpose |
| approval_required | Blocks direct mutation at the public boundary | Create a Lead360 draft and obtain explicit approval |
| unavailable | Scope, service, registry, or policy does not authorize the operation | Stop and review access instead of probing alternatives |
A 409 approval_required result is expected for customer-record writes, internal writes, destructive actions, external sends or publishing, and financial effects. It is not evidence that the client should retry with another endpoint.
MCP execution
Call tools/call with name execute_operation and arguments containing operation_key plus the operation arguments object. MCP returns tool content, structuredContent, and isError. A policy or validation failure is represented as an MCP tool result with isError true and a structured error code and message.
{
"jsonrpc": "2.0",
"id": 4,
"method": "tools/call",
"params": {
"name": "execute_operation",
"arguments": {
"operation_key": "contacts.profile.read",
"arguments": {"contact_id": 12345}
}
}
}Frequently asked questions
Why is a yellow or red operation visible if it cannot execute directly?
Discovery explains the reviewed contract and required approval mode. Visibility does not bypass the Lead360 draft, target review, confirmation, or apply controls.
Can the client supply another location ID?
No. The credential location is authoritative and tenant-related operation arguments are rejected.
How should I handle personal data in a read result?
Use only what the approved purpose requires, avoid sensitive logs, restrict downstream access, apply the correct retention policy, and support access or deletion obligations.
Continue with Lead360
Use this workflow in Lead360
Put this guide into practice with a 14-day free trial of Lead360 Pro early access, or continue learning through the related collection.