Workflow connectors

Importable n8n, Make.com and Zapier workflows that create a filesystem, check usage, mint a one-time mount ticket and revoke the session.

n8n, Make.com and Zapier call Mountable's control-plane API. They do not mount the filesystem. The workflow holds MOUNTABLE_API_KEY. The sandbox step receives only the one-time ticket. Storage and downloads are billed, so create a filesystem once and reuse its id.

The importable files are on this site under /integrations/. Publishing a directory listing needs the owner's marketplace account; importing a blueprint does not.

Calls

Send Authorization: Bearer and the API key from the workflow's secret store. Replace ORG_ID with api_key.org_id from the first call.

curl -sS -H "Authorization: Bearer $MOUNTABLE_API_KEY" https://mountable.io/api/v1/me
 
curl -sS -H "Authorization: Bearer $MOUNTABLE_API_KEY" -H "Content-Type: application/json" \
  -d '{"name":"agent-workspace"}' \
  https://mountable.io/api/v1/orgs/ORG_ID/filesystems
 
curl -sS -H "Authorization: Bearer $MOUNTABLE_API_KEY" \
  https://mountable.io/api/v1/orgs/ORG_ID/filesystems/FS_ID/usage
 
curl -sS -H "Authorization: Bearer $MOUNTABLE_API_KEY" -H "Content-Type: application/json" \
  -d '{"filesystem_id":"FS_ID","mode":"rw","idempotency_key":"job-42","max_duration_seconds":3600}' \
  https://mountable.io/api/v1/mount-sessions
 
curl -sS -X DELETE -H "Authorization: Bearer $MOUNTABLE_API_KEY" \
  https://mountable.io/api/v1/mount-sessions/SESSION_ID

Creating a filesystem is not idempotent. After a timeout, list filesystems before creating the same name again. A repeated mount-session create with the same idempotency_key returns the existing session and a null ticket. If state is still requested, the ticket was lost: revoke that session and create again with a new key. If state is active or later, keep the working mount. Do not send a null ticket to the sandbox. The full rules are on Agents.

max_duration_seconds in these templates is 3600 (the API allows 60 to 604800 and defaults to 43200 when the field is omitted). Revoke still runs when the sandbox step finishes. A revoked mount stops admitting new operations within 15 seconds.

The sandbox command, with the ticket in MOUNTABLE_TICKET and not in an argument, is:

mkdir -p /mnt/mountable && printf '%s\n' "$MOUNTABLE_TICKET" | mountable mount --ticket-stdin --json /mnt/mountable

Wait for {"event":"mounted"}. The sandbox needs Linux FUSE (/dev/fuse).

n8n

Import these workflows (menu, Import from file). Create a Header Auth credential named Mountable API key: header name Authorization, value Bearer plus the API key. Attach it to every Mountable HTTP node. Do not put the key in the workflow file.

• /integrations/n8n/create-filesystem.workflow.json replaces REPLACE_WITH_FILESYSTEM_NAME and runs once.
• /integrations/n8n/sandbox-job.workflow.json replaces REPLACE_WITH_FILESYSTEM_ID and the sandbox URL. The shipped URL is https://example.invalid/mountable-sandbox, so a trial run does not send the ticket anywhere. The idempotency key is String($execution.id), because the API requires a string and the execution id is a number. The sandbox node has no Mountable credential. If the ticket is missing and the session is still requested, the workflow revokes that lost ticket.

The community-node contract for the same five operations (who am I, create filesystem, usage, create mount session, revoke) is /integrations/n8n/node-spec.json. The HTTP workflows are the connector you can import today.

Make.com

In a new scenario, choose the menu, Import blueprint, and save. The first module is a webhook so the scenario has a trigger. On each Mountable HTTP module, replace Bearer REPLACE_WITH_API_KEY with the key from a Make connection. Do not share a blueprint after the key is in it. HTTP responses are read from data (for example {{2.data.api_key.org_id}}).

• /integrations/make/create-filesystem.blueprint.json is one-shot. Turn the scenario off after one success. POST /orgs/{org_id}/filesystems is not idempotent, so every later webhook creates another billed filesystem.
• /integrations/make/sandbox-job.blueprint.json

The sandbox module posts to https://example.invalid/mountable-sandbox and sends no Authorization header. Replace that URL with your worker, and replace REPLACE_WITH_FILESYSTEM_ID. Each webhook body must include a new string field idempotency_key. The create-session module sends it as {{1.idempotency_key}}. If that field is missing, the scenario requests https://example.invalid/missing-idempotency-key with no error handler, so the run stops as an error instead of replaying a stored key. After the session is created, a router sends the bundle one of two ways:

• data.ticket exists: call the sandbox, then revoke. The sandbox module's error handler is Ignore, so a connection failure still reaches revoke.
• data.ticket is missing and data.state is requested: revoke only.

Any other state stops without calling the sandbox and without revoking an active mount. The custom-app contract is /integrations/make/app-spec.json.

Zapier

/integrations/zapier/ is a Zapier Platform app with creates for a filesystem, a mount session and revoke, and a search for usage. Authentication calls GET /api/v1/me. It is not in the Zapier directory yet. From that directory, with the owner's Zapier CLI logged in:

npm install
zapier push

Until that listing exists, a Zap can call the same URLs with Zapier's HTTP action and a stored API key. Keep that key off the sandbox step.