This works great for providers that publish Swagger/OpenAPI specs. Unfortunately, Slack happens to be amongst those that don’t.

Just here for the spec? Grab it directly: slack-openapi-spec.json — 272 endpoints, 134 webhooks, 1,526 schemas, updated weekly.

Or, play around with it, directly in your browser, in Swagger’s online editor.

The problem

In 2024, Slack officially “terminated” their public OpenAPI specification. If you go looking for one now, you’ll find a graveyard of stale community specs, half-working scrapers, and specs that silently drop fields because Slack’s API types are genuinely complex — intersection types, literal string discriminators, deeply nested unions, dynamic RPC payloads.

We needed a complete, accurate spec for Strata’s Slack integration. Nothing we found was complete and up-to-date. So we built a generator!

The approach: read the source of truth

Here’s the key insight: Slack may have abandoned their OpenAPI spec, but their official Node SDK (@slack/web-api, @slack/bolt, @slack/types) is actively maintained and meticulously typed. The TypeScript type definitions are the spec — they’re just in an inconvenient format.

So rather than scraping docs or reverse-engineering API responses, the generator uses ts-morph to parse the Abstract Syntax Tree of the SDK’s TypeScript declarations and transpile them into OpenAPI 3.1.0.

No web scraping. No API calls. No guessing. Just reading the types (and docs!) that Slack’s own engineers maintain.

How it works under the hood

The generator runs through a few stages:

1. Load the SDK’s type declarations. ts-morph ingests all the .d.ts files from the three Slack packages into an in-memory AST with strict null checks enabled.

2. Walk the Methods class. The SDK declares every API endpoint as a nested property on a Methods class. The generator recursively walks this tree — each leaf is typed as MethodWithRequiredArgument<Args, Response> or MethodWithOptionalArgument<Args, Response>, so extracting the request and response types is straightforward. Property paths map directly to endpoint names: files.uploadV2 becomes /api/files.uploadV2.

3. Convert TypeScript types to OpenAPI schemas. This is the hard part. The type mapper handles:

• Unions → anyOf, with optimizations like collapsing string literal unions into a single enum and hoisting common properties across branches

• Intersections → allOf, with inline object squashing so you don’t get needlessly nested schemas

• Generics → resolved by following defaults and constraints

• Circular references → broken with placeholder schemas and lazy thunks

• Name collisions → when two packages export a type with the same name (e.g., Bolt’s Authorization vs. web-api’s Authorization), the registry auto-disambiguates with numbered variants

4. Extract webhooks. Interfaces ending in Event, Action, or Shortcut from Bolt’s type definitions become webhook schemas, wrapped in the standard EnvelopedEvent envelope.

5. Detect binary fields. The generator recursively scans schemas for format: "binary" and automatically adds multipart/form-data as a content type for those endpoints — so file upload endpoints Just Work.

Staying up to date

A schema is only useful if it’s current. A GitHub Action runs weekly: it installs the latest versions of all three Slack packages, regenerates the spec, and auto-commits if anything changed. No manual maintenance required.

Why we open-sourced it

We built this for Strata, but there’s no reason to keep it proprietary. We’ve pulled numerous community-maintained OpenAPI specs for use in our product, and we’d love to be a good neighbor and return the favor.

Anyone building Slack integrations — whether you’re generating client SDKs, feeding API context to LLMs, setting up Postman collections, or building documentation — can use the generated spec directly.

You can grab the latest spec from the repo: slack-openapi-spec.json

Or clone the repo and generate it yourself:

git clone https://github.com/connectstrata/slack-openapi-generator.git
cd slack-openapi-generator
npm install
node generate.js

What’s next

If you use the spec and run into edge cases — missing endpoints, type inaccuracies, TypeScript patterns that aren’t handled — we’d love to hear about it. Open an issue or submit a PR.

And if the idea of connecting APIs without writing glue code sounds interesting, check out Strata — it’s the project that started all of this.

Data transformations are the heart of any integration. A good integration developer builds a mental model for each system and create pipelines that account for data in all of its glorious messiness.

We built an evaluation suite that tests LLMs on their ability to assume the integration developer role. We constructed 20 real-world data transformation scenarios spanning popular marketing platforms like Shopify, Salesforce, HubSpot, Braze, Klaviyo, and more. Each scenario requires the model to read source and target JSON schemas, interpret natural-language mapping instructions, and produce a working transformation that passes strict schema validation.

Best models for data integration mapping

You don’t always need the biggest model

With accurate schemas, frontier LLMs reliably generate correct transformation code, even across complex, deeply nested structures. Surprisingly, Claude Haiku 4.5 scored a 98.3% which matched the performance of the larger and more capable Opus 4.6 model. This indicates that the data transformation tasks are unlikely to benefit from further model improvements. As model capabilities continue to improve, reaching for the highest intelligence option will be increasingly unnecessary. Evals are critical for identifying the right level of capability for a given task.

Evaluation structure

The evaluation measures whether an LLM can produce a JavaScript function that correctly transforms a set of SaaS webhook payload and API response objects into a desired SaaS API request body.

For each completion, the LLM is provided:

1. Source schemas — JSON schemas for one or more integration resources, such as a Shopify customer created webhook payload or a Contact object from the Salesforce API

2. Target schema — The JSON schema for an integration resource to which the output must conform (e.g. a Braze update user API request body)

3. Natural-language instructions — Plain english instructions describing which fields to map. The instructions are intentionally terse and do not use precise field names in order to reflect real-world user prompts.

4. Common data mapping guidelines — A checklist of things to ensure before responding to the user (e.g. type conversions, date-time formatting, null handling, etc…)

The response is scored by executing the generated JavaScript function against real example data from the source API or webhook. A binary pass / fail score is assigned based on whether the resulting object passes JSON validation for the target schema. To measure reliability rather than single-pass results, each test case is evaluated 3 times for a total of 60 test case evaluations per model.

Test case design

The test cases are drawn from real customer integration scenarios and span three difficulty levels:

• Low (7 tests): Single-source, straightforward field mapping. Tests basic schema comprehension and field correspondence.

• Medium (7 tests): Multi-source merging, date formatting, type conversion, array construction, and distractor filtering (irrelevant sources included in the input).

• High (6 tests): Complex nested structures, multi-source cross-referencing, deep flattening, dual-target outputs, and date/format transformations.

Future plans

This benchmark is a starting point, and there are many planned improvements including:

• More models — Expand to include the Gemini model family and GLM-5

• More test cases — Add scenarios covering additional API platforms and edge cases like malformed data

• More inputs — Execute the LLM-generated data transformation against more than one example input

We’re also exploring whether a purpose-built DSL for JSON transformations can match the performance of general purpose programming languages while providing better static analysis capabilities.

The full evaluation suite and results are available on GitHub.