Help / FAQ
Clear answers about what FetchSet resolves, how usage is metered, what “fresh” means, and how personal data is handled.
FetchSet is an identity-resolution and contact-enrichment service built for automated workflows. Give it an email, LinkedIn URL, name, company domain, or IP and it returns the most useful person or company record it can verify.
The same resolution surface is planned for REST and MCP, so it can be called from back-end systems, Clay recipes, agent workflows, or conversational MCP clients.
The primary users are technical GTM and RevOps teams, agent builders, founders, and solo sellers who already work with APIs, Clay, Claude, or custom automation.
FetchSet assumes the caller is a workflow or agent. The human dashboard is intentionally limited to account, keys, billing, and usage.
No. FetchSet is the data and resolution layer. It will not include a prospecting database UI, dialer, sequencer, call recorder, or outreach-sending product.
The planned dashboard exists only for signup, API keys, MCP connection, plan management, token top-ups, and usage reporting.
Both lead to the same tools and response contract.
REST uses an fs_ Bearer key. MCP is planned with OAuth 2.1, PKCE-S256, and Streamable HTTP.
The planned surface covers:
Email and reverse-resolution tools are planned first. Search, mobile, IP-to-company, and MCP follow in the next phase. Availability will be labeled per tool.
The product requirement is that every returned email carries a validation date less than 30 days old. If the freshest known validation is older, FetchSet must revalidate the address or withhold it.
Freshness is returned as data instead of being hidden behind a generic quality badge, so your workflow can apply its own policy.
Email validation and identity confidence are separate signals. The planned email response includes a deliverability classification such as valid, risky, catch_all, or invalid, plus the validation date.
FetchSet supplies the evidence; your sending policy determines which classifications are acceptable. Invalid values are not returned as usable emails.
The mobile tool is planned to run carrier or HLR validation and return mobile numbers only. Landlines and invalid values are dropped.
Because mobile verification is a paid real-time operation, a successful mobile result is currently modeled at 10 external tokens. An empty result costs zero.
The intended model combines a redistribution-licensed dataset with approved external providers for cache misses and validation. Vendor output can be cached or resold only when the underlying contract explicitly permits it.
Every stored personal-data record must carry source, acquired_at, and redistribution_basis. The public sub-processor list is required to name upstream data vendors as well as infrastructure providers.
Coverage varies by identifier, geography, role, and company. We will not publish a universal match-rate claim before the launch vendor bake-off is complete.
The best evaluation is a representative sample from your own workflow. FetchSet plans to make empty results free, which makes side-by-side testing straightforward.
The current plan is US-first and business-email-first. International availability depends on licensed coverage, field-level resale rights, and the privacy obligations that apply in each market.
We are not publishing an EMEA, APAC, or Canada launch date until those requirements are closed.
The current product plan models four tiers:
| Tier | Price |
|---|---|
| Free | $0 |
| Starter | $27/mo |
| Growth | $97/mo |
| Scale | $997/mo |
The founding beta is capped. Founding members lock in unlimited database lookups at GA within plan rate limits, plus a monthly allocation of external tokens. Final limits and allocations remain subject to the financial model and pre-launch pricing review.
At GA, a fresh result already present in the FetchSet database will not consume an external token on paid plans. The current founding beta remains capped while the product and activation path are validated.
Unlimited will not mean unbounded traffic. Requests and returned records remain subject to per-plan rate limits and a Fair Use Policy. Paid external providers are never placed behind an uncapped action.
An external token represents a successful lookup that required a paid provider outside the fresh FetchSet cache.
| Returned data | Current model |
|---|---|
| Externally found email | 1 token |
| Carrier-verified mobile | 10 tokens |
| Empty result | 0 tokens |
The response reports tokens_charged so the cost is visible to both people and agents.
No. Charge-on-success is a billing invariant, not a promotional exception. A processed miss returns an empty result with tokens_charged: 0.
Retries are planned to be idempotent and tied to the resolution result, so replaying the same operation does not create a second charge.
The current plan offers top-ups beginning at 100 tokens for $5, with lower per-token pricing at higher volumes.
Purchased tokens do not expire while the account remains active. Plan-included tokens may roll over for one additional month. The planned consumption order uses older included tokens first, then current included tokens, then purchased tokens. Remaining tokens are removed when cancellation takes effect.
REST requests use a Bearer key beginning with fs_. Keys are created and revoked in the account dashboard, displayed once, and stored hashed.
MCP is planned to use OAuth 2.1 with PKCE-S256 instead of a long-lived client secret. That lets compatible clients authorize FetchSet without copying an API key into a conversation.
A valid request that finds no data is still a processed success: HTTP 200, status: "ok", an empty results object or array, and tokens_charged: 0.
Malformed input, invalid authentication, and rate limits use consistent 4xx error responses instead.
Batch support is tool-specific. The planned mobile endpoint accepts up to 100 LinkedIn URLs in one batch. Other tools will document their accepted single and batch request shapes explicitly.
Large or retryable batch jobs may run through background processing even when interactive single lookups stay synchronous.
No. The planned get_account, get_billing, and get_usage tools are free to call.
They expose the current plan, renewal state, balances, per-tool costs, and usage breakdown so an agent can monitor its own activity without spending data credits.
FetchSet must ship a public privacy-choices and data-subject-request flow before launch. Access, deletion, objection, and “Do Not Sell or Share” requests route to the same suppression system.
Deletion removes the stored record and writes a permanent suppression entry so a future cache refresh does not reacquire and return the same person.
The suppression list is checked before any personal data leaves the resolution pipeline, including on cache hits. A suppressed subject returns the same empty envelope as a genuine miss and costs zero tokens.
The response does not reveal that a person is suppressed.
Launch is gated on a live Privacy Policy, Terms, DPA, compliance page, named sub-processor list, “Do Not Sell or Share” control, and GDPR Article 14 source-transparency notice.
Global Privacy Control signals must be honored, and California DROP requests must be polled and processed on the required cadence. These are product requirements, not footer placeholders.
Not at this stage, and we will not claim a certification before an audit is complete. SOC 2 timing and cost are part of the pre-launch and enterprise-readiness plan.
The technical baseline still requires encryption in transit and at rest, least-privilege access, audit logging for personal-data access, secret management, and no personal data in application logs.
No. Advertising-audience, MAID, and identity-graph endpoints are not part of the v1 product. Reserved routes return 403 feature_disabled.
That surface is legally and operationally distinct from contact resolution and remains gated behind separate counsel, sourcing, and go/no-go review.