Skip to main content
Human guide: work with your agent → Inspect one Wiza action before starting provider-backed work. Your first result is a verified input and output contract.

​
Provider-specific requirements

wiza_search_prospects discovers prospects by title, level, company, industry, and location. It returns masked profiles without contact information, with up to 30 results per search.
The response is { prospects: [...], total: N }. Do not expect more than 30 results per call. Use structured locations (v, b, s) for new payloads. older aliases remain accepted and normalized. wiza_get_individual_reveal reads an existing reveal. wiza_get_credits reads account credits. Use these operations only for data the user is authorized to access. Do not recommend Sales Navigator saved-search scraping or browser-session credential reuse.

​
SDK/API reveal contract

The existing SDK/CLI/API reveal operation remains available. Its OpenAPI-native payload accepts individual_reveal plus enrichment_level. older aliases still normalize before dispatch. Reveals are queued and polled to a terminal state. The levels are none (profile), partial (email), phone, and full (email and phone). A reveal returns a flat object with email, phone_number1, mobile_phone1, and status (finished or failed). The terminal result’s credits.api_credits.total, when present, determines settlement. Without that credits object, settlement uses returned contact fields rather than the requested level. Budget email and phone work separately. no intermediary agreement establishes authorization from the source platform.

​
Find an applicable action

Confirm your effective workspace, then search the live catalog:
Search returns candidates. Check the returned provider and operation rather than selecting a similar title automatically.

​
Inspect the selected contract

Replace <returned-tool-id> with the identifier returned by discovery:
These commands do not execute the selected provider action. Read its required inputs, supported access mode, pricing unit, outputs, and limits. A connection does not establish that every action supports BYOK. Follow the provider-specific requirements above and the live action contract.

​
Prepare one reviewed input

Use one authorized record that matches the inspected schema. Preserve its source identity and define the result you will accept. Open the action reference for its payload and response shape. Provider-backed execution can incur usage or external effects. For reusable logic, follow Write Plays. For direct-call recovery, use Tool execution recovery.
Continue only when the workspace, provider, required fields, acceptance rule, and applicable price are understood. Keep unavailable access separate from no-result evidence.