Methodology · Dataset v0.1.2

How Ablelume verifies native support

Ablelume answers a narrow question: does Zapier, Make or n8n support this exact app operation through its own built-in integration? This page explains what counts, how each record is classified and where the evidence comes from.

Scope of Dataset v0.1.2

The dataset covers 3 platforms (Zapier, Make and n8n) and 12 apps. Each app has 8 canonical operations: specific jobs such as “New Order” or “Send Email”, defined once and checked on every platform. That gives 96operations and 288 capability records (one per operation per platform):249 TRUE, 32 FALSE and 7 UNKNOWN.

Operations have one of three types:

TRIGGER

An event that starts a workflow, such as a new form response.

ACTION

An operation that creates or changes something in the app.

SEARCH_READ

A lookup, list, get or search that does not primarily change the app.

An action or read capability is never mapped to a trigger, and the reverse.

What counts as native support

An operation is native on a platform when the platform's own app integration (a Zapier app, a Make module, an n8n node) performs that exact job, without falling back to something generic. Specifically:

• Native ≠ API possible. Most apps have an API; that alone proves nothing about the platform.
• Native ≠ generic HTTP request. Calling the app's API from an HTTP module or node is a workaround.
• Native ≠ generic webhook. Receiving the app's webhooks in a catch-all webhook step is a workaround.
• Native ≠ custom code. Code steps can do almost anything, which is why they do not count.
• Native ≠ community node. Third-party community extensions are not part of the platform's built-in support.

Similar is not the same. A capability that is close to the job but not equivalent (an action where a trigger is needed, or a generic event that might include the case) does not make the operation native.

Native support states

TRUE

The exact job is available through the platform's native integration, without generic HTTP/API, webhook, custom code, community node or custom app fallbacks.

FALSE

The platform's current official native scope gives strong evidence that the exact job is not exposed. Similar but non-equivalent capabilities do not count.

UNKNOWN

The evidence is insufficient, contradictory or too generic to defend TRUE or FALSE. UNKNOWN is a deliberate result, not missing work: it is kept instead of being forced into a yes or no.

Each record also has a native class describing where the capability comes from:

FIRST_PARTY_NATIVE

Built in, shipped and documented by the automation platform itself.

VERIFIED_NATIVE

Present in the platform's official directory or docs, but who maintains the integration is not established. Zapier records use this conservative class.

NOT_NATIVE

The job is not natively exposed; a workaround may exist.

UNKNOWN

The support class cannot be defended from the evidence.

What a capability record contains

Delivery mode

How the step runs: webhook (event pushed to the platform), polling (checked on a schedule),instant undisclosed (the platform labels it instant but the mechanism is not proven),request/response (a direct action or lookup), not applicable (no native support) orunknown.

Support status

Active, or a qualifier: limited (a material condition narrows it), beta,deprecated, legacy, not supported or unknown.

Requirements

A plan or account condition, recorded only when the source states one. An unknown requirement is never shown as a requirement.

Limitations

Material conditions found in the source, such as an event scope that is narrower than the canonical job.

Workarounds

For non-native records: whether an API, webhook, custom code or community route is documented for that job. These describe known alternatives, not native support.

Evidence sources and verification dates

Every record cites at least one official source: the platform's operation documentation, its integration directory or, for n8n, its source repository. Some records add supporting sources. Each source carries the date it was checked, and each record carries the date it was verified. Dataset v0.1.2 records were verified between 2026-10-05 and 2026-10-07.

Evidence strength describes how directly the source supports the conclusion:

A_DIRECT

The exact capability appears in current official documentation.

B_STRONG

The official evidence is clear but indirect, for example a parameter on a generic native module, or the absence of the job from a complete module list.

C_PARTIAL

Relevant official evidence exists but is not enough to assert TRUE or FALSE. These records are UNKNOWN.

D_UNRESOLVED

Sources are insufficient or contradict each other after investigation.

How the checker combines two steps

A workflow is a trigger in App A followed by an action in App B. For each platform, the result isYES only if both steps are TRUE, NO if either step is FALSE, andUNKNOWN otherwise. An unknown step is never rounded up to a yes.

Data updates & corrections

The current release is Dataset v0.1.2. Releases are versioned: a new release is published when evidence is revalidated or replaced, and the version shown across the site changes with it.

• Every record shows its verified date. A date tells you when the evidence was checked, not that it is still current today.
• Zapier, Make and n8n change their integrations, and vendors rename or remove modules. A conclusion can change when the evidence does.
• UNKNOWN records can move to TRUE or FALSE when better evidence appears; they are not quietly guessed in the meantime.
• Broken or outdated source links are replaced with current official sources. If the new source supports the same conclusion, only the source and its checked date change.
• There is no fixed review schedule; records are revalidated when a source changes or an error is reported.

If you find an incorrect record, a broken source or an outdated capability, emailcontact@ablelume.com with the app, operation and platform. More options are on the contact page.