* feat(integrations): add ZoomInfo, align Wiza, audit Apollo, refresh docs - Add ZoomInfo integration: search/enrich contacts & companies, intent, news (6 tools), proxy route, block, and icon - Validate and align Wiza tools/block/outputs against live API docs - Audit Apollo tools: tighten params, outputs, and types - Update tool docs (.mdx), icons, icon mappings, and integrations.json * fix(zoominfo): use useId for ZoomInfoIcon clipPath to avoid duplicate DOM ids Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(apollo): address PR review on sequence add and bulk enrich - sequence_add_contacts: send large contact_ids/label_names arrays in the POST body (Rails merges query + body params) to avoid reverse-proxy URL length limits; keep scalar settings in the query string - organization_bulk_enrich: add back-compat shim mapping the legacy `organizations` ({name, domain}[]) subBlock value to the new `domains` string array so saved workflows keep running Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(integrations): unique ZoomInfo icon clip id, numeric employee range filters - ZoomInfoIcon: derive clipPath id from useId() so multiple instances don't collide - ZoomInfo company search: send employeeRangeMin/Max as numbers, matching revenueMin/Max * fix(zoominfo): send employeeRange filters as strings per API schema Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(zoominfo): send contactAccuracyScoreMin as string per Contacts Search schema Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(apollo): harden people_search pagination, correct bulk-update output docs - people_search: read pagination from both the nested `pagination` object (legacy /mixed_people/search) and top-level fields, avoiding silent fallback to defaults - account_bulk_update: correct output descriptions — accounts support up to 1000 per request and async is opt-in (not auto-triggered at 100 like contacts) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(wiza): correct company enrichment credits shape in output docs Company enrichment returns api_credits { total, company_credits }, not the email/phone/scrape breakdown used by individual reveals. Description-only fix verified against docs.wiza.co. * fix(apollo): send sequence add contact_ids/label_names as query params per docs Apollo documents every field for emailer_campaigns/:id/add_contact_ids as a query parameter with no request body. Append contact_ids[]/label_names[] to the query string instead of the JSON body to match the documented contract. * feat(apollo): expose account_stage_id uniform field for bulk update accounts Apollo documents account_stage_id as a Body Param for /accounts/bulk_update ('when using account_ids, apply this account stage to all accounts'). Adds it to the tool params, body builder, type, block subBlock, and params mapper alongside name/owner_id. * docs(apollo): correct contact_update typed_custom_fields description Apollo's update-a-contact endpoint documents typed_custom_fields, so drop the inaccurate "not officially documented" caveat. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(zoominfo): default required outputFields on enrich; parse nested API error object - ZoomInfo enrich endpoints require outputFields; send a curated default set when omitted so requests don't fail - extractZoomInfoError now reads the GTM REST nested error object ({error:{code,message}}) instead of dropping it to a generic HTTP message Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * improvement(wiza): add wandConfig to complex prospect-search filter fields Adds AI-assist wandConfig (json-object) with format examples to the structured filter inputs (job_title, job_company, past_company, company_industry, location, company_location) and the full filters object, completing the wandConfig checklist item for the Wiza block. * fix(findymail): surface API .error messages and alphabetize registry - transformResponse error branches now fall back to the response body's `error` field before the generic status string, so Findymail's actual messages ("Not enough credits" on 402, "Subscription is paused" on 423, "One identifier is required..." on 422) reach the user instead of a bare "Findymail API error: <status>". Applied to all 11 tools. - alphabetize the findymail entries in tools/registry.ts to match the already-alphabetical import block and the integration guideline. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Block Documentation Generator
This directory contains scripts to automatically generate documentation for all blocks in the Sim platform.
Available Scripts
generate-docs.ts: Generates documentation for all blocks. Run viabun run generate-docsfromapps/sim, or directly withbun run scripts/generate-docs.tsfrom the repo root.
How It Works
The documentation generator:
- Scans the
apps/sim/blocks/blocks/directory for all block definition files - Extracts metadata from each block including:
- Name, description, and category
- Input and output specifications
- Configuration parameters
- Generates standardized Markdown documentation for each block
- Updates the navigation metadata in
meta.json
Running the Generator
# From the repo root
bun run scripts/generate-docs.ts
Dependencies are managed by Bun workspaces — bun install at the repo root installs everything needed.
CI Integration
The documentation generator runs automatically as part of the CI/CD pipeline whenever changes are pushed to the main branch. The updated documentation is committed back to the repository.
Adding Support for New Block Properties
If you add new properties to block definitions that should be included in the documentation, update the generateMarkdownForBlock function in scripts/generate-docs.ts.
Preserving Manual Content
The documentation generator now supports preserving manually added content when regenerating docs. This allows you to enhance the auto-generated documentation with custom examples, additional context, or any other content without losing your changes when the docs are regenerated.
How It Works
- The generator creates clean documentation without any placeholders or markers
- If you add manual content to a file using special comment markers, that content will be preserved during regeneration
- The manual content is intelligently inserted at the appropriate section when docs are regenerated
Using Manual Content Markers
To add custom content to any tool's documentation, insert MDX comment blocks with section markers:
{/_ MANUAL-CONTENT-START:sectionName _/}
Your custom content here (Markdown formatting supported)
{/_ MANUAL-CONTENT-END _/}
Replace sectionName with one of the supported section names:
intro- Content at the top of the document after the BlockInfoCardusage- Additional usage instructions and examplesconfiguration- Custom configuration detailsoutputs- Additional output information or examplesnotes- Extra notes at the end of the document
Example
To add custom examples to a tool doc:
{/_ MANUAL-CONTENT-START:usage _/}
## Examples
### Basic Usage
```json
{
"parameter": "value",
"anotherParameter": "anotherValue"
}
```
Advanced Configuration
Here's how to use this tool for a specific use case... {/_ MANUAL-CONTENT-END _/}
When the documentation is regenerated, your manual content will be preserved in the appropriate section automatically. The script will not add any placeholders or markers to files by default.