Find and verify B2B contact data with Wiza: individual reveals, list enrichment, prospect and company search, company enrichment and credit balance.
Wiza ships in the w6w first-party pack. It declares 13 actions, 3 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.wizaWiza finds and verifies work emails and phone numbers for sales and recruiting prospects. This app reveals a single contact from a LinkedIn profile URL, an email, or a name plus company, asynchronously, and reads the result back; enriches whole lists of up to 2500 people; and builds lists straight from Wiza’s prospect database with its job, location, company-size, technology and funding filters.
It also searches companies, enriches a company synchronously from a name, domain or LinkedIn identifier, resolves the exact location and technology values the filters demand, and reads the credit balance.
Health checks track Wiza’s own status page (the API component), whether the API is serving, and the API credit balance.
Three routes to the same 13 actions. The Workflow tab is generated from Wiza's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
continue-prospect-search Continue a previous prospect search into a new batch (POST /api/prospects/continue_search), reusing the filters of an earlier Create Prospect List. Returns a list to poll with Get List. An unknown list id is HTTP 404 and fails the action; a paused service is a 503, retry shortly.
create-list Create a list of people to enrich (POST /api/lists): up to 2500 items, each a LinkedIn profile URL, an email, or a full name with a company or domain. Asynchronous: returns the list at once with its status; poll Get List, then read Get List Contacts. A completed list also posts to the webhook. Not every list succeeds (LinkedIn rate limiting).
create-prospect-list Create a list of prospects matching your filters and enrich them (POST /api/prospects/create_prospect_list). Asynchronous: poll Get List, then read Get List Contacts. `maxProfiles` caps the results. To take more from the same search later, use Continue Prospect Search. List creation can answer 503 while paused for maintenance; nothing is created, retry shortly.
enrich-company Enrich a company synchronously (POST /api/company_enrichments) from a name, domain, LinkedIn ID or LinkedIn slug: industry, size, revenue, funding, location and socials. 2 API credits, charged only when a company is found. A company that cannot be found is HTTP 404 and fails the action. Limits: 30 requests/minute, 43,200/day.
get-credits Read the credits remaining on the account (GET /api/meta/credits): email, phone, export and API credits. Email and phone credits are the string "unlimited" on an unlimited plan.
get-individual-reveal Read an individual reveal by id (GET /api/individual_reveals/{id}). Poll until `is_complete` is true; `status` is queued, resolving, finished or failed. A billing problem is NOT an HTTP error: the call is a 200 and the record is `failed` with `fail_error: "billing_issue"`.
get-list Read a list's status, stats and credits by id (GET /api/lists/{id}). Poll it after Create List or Create Prospect List, then read the contacts. Check `status`: a list can fail (LinkedIn rate limiting). An unknown id is HTTP 404 and fails the action.
get-list-contacts Read the contacts of a list as JSON (GET /api/lists/{id}/contacts?segment=...). `segment` is required: people (all), valid (only valid emails) or risky. The response is not paginated in the reference. A list with nothing to export is HTTP 400 "No contacts to export" and fails the action.
search-companies Search companies by firmographic, location, growth and funding filters (POST /api/accounts/search). Send `filters` to start a search, or only the `pageToken` from the previous response (no filters) to fetch the next page. Every returned company costs 0.5 API credits; `size` defaults to 0 (count only), and the usual maximum is 30. An empty-credit account is a 400 and fails the action; the rate limit is a 429.
search-locations Resolve a location prefix (3+ characters) to the exact values the prospect search `location` and `company_location` filters accept (GET /api/meta/location_autocomplete). Each result's `bucket` is the filter's `b` value (city, state, country, continent or group) and `key` its `v`.
search-prospects Count the prospects matching a set of filters, and optionally preview up to 30 of them (POST /api/prospects/search). `size` defaults to 0, which returns only the total. Previewed profiles carry no email or phone: create a prospect list to enrich them. Returned profiles are billed in API credits (see `credits`).
search-technologies Resolve a technology name or slug prefix (3+ characters) to the slugs the prospect and company search `technologies` filter accepts (GET /api/meta/technology_autocomplete).
start-individual-reveal Start a single-contact enrichment (POST /api/individual_reveals) from a LinkedIn profile URL, an email, or a full name plus a company or domain. It is asynchronous: this returns an id and status immediately; read the result with Get Individual Reveal or let the webhook deliver it. Credits are charged only when data comes back (1 profile, 2 email, 5 phone).
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying Wiza's real ids.
{
"manifestVersion": "2",
"name": "wiza-example",
"steps": [
{
"id": "continue-prospect-search",
"uses": {
"app": "io.w6w.wiza",
"action": "continue-prospect-search",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"id": "<id>"
}
}
]
}continue-prospect-search create-list create-prospect-list enrich-company get-credits +8 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for Wiza, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to Wiza. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "continue-prospect-search",
payload: {
id: "<value>",
// maxProfiles: "<value>",
// callbackUrl: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action continue-prospect-search --payload '{"id":"<value>"}' Give an AI agent Wiza — without giving it Wiza's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.wiza#continue-prospect-search",
"input": {
"id": "<id>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's Wiza connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Wiza's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. Wiza itself is MIT, and the runtime that executes it is source-available (FSL).
Wiza declares its own checks, so its health is a property of the app rather than something the host guesses at.
The "Wiza API" component from status.wiza.co, plus the rest of Wiza's own status page for visibility.
An unauthenticated GET /api/meta/credits. The documented `Invalid API key.` error envelope proves the Wiza API is serving; it says nothing about any credential.
Remaining API credits from a signed GET /api/meta/credits.