Transloadit is enterprise-ready
Every security questionnaire asks the same things. Who can sign in, and how do you remove them? What can a leaked key do? What do you commit to in writing? Transloadit now has a clear answer to each, so your review can move on to the next vendor.
Single sign-on for your Workspace
Members of Enterprise Workspaces can now sign in to the Console through SAML 2.0. Your identity provider authenticates teammates; Transloadit Workspace membership, invitations, and seat limits still determine their access.
SSO is in early access, so it starts with us: email our sales team, and we enable it for your Workspace and help you set it up. The Workspace owner then opens Settings, then Single sign-on (SAML) in the Console. There they copy our service provider entity ID, ACS URL, and metadata URL into the identity provider, and paste the identity provider's entity ID, SSO URL, X.509 certificate, and email attribute back into Transloadit. Owners who sign in with a password must confirm it when a new elevated session is needed. The identity provider must sign its assertions and send a stable, non-transient NameID.
Teammates then choose Continue with SSO on the login page and enter their Workspace slug. A few details that security reviewers tend to ask about:
- Provisioning. In the Console, turn on Allow just-in-time user provisioning to let people without a Transloadit account join with the User role on their first sign-in, within your plan's seats, including pending invitations. Someone who already has an account but is not a member needs an invitation, even with this option enabled. New members joining through an SSO invitation also receive the User role; existing members keep their roles. With provisioning off, only existing members and invited people can sign in.
- Offboarding. Disabling someone at your identity provider blocks new SSO sign-ins, not an existing session or another sign-in method. Remove their Workspace membership separately; their access to that Workspace ends on their next request. Rotate or delete every Auth Key whose secret they created, viewed, or otherwise had access to as well.
- Scope. SSO sits next to password sign-in rather than replacing it, and logins start at Transloadit (SP-initiated). Members who already have a password can still use it.
Passkeys as your second factor
Two-factor authentication in the Console used to mean a six-digit code sent by email. You can now use a passkey instead: Face ID, Touch ID, or a hardware security key. A passkey only works on the site it was created for, so a look-alike login page cannot phish it.
In the Console, open User settings, then Sign-in security, then Two-factor authentication, choose Passkey, and follow your browser's prompt. In a password-authenticated session, you can switch back to email codes. Passkeys apply to accounts that sign in with a password. Google, GitHub, and SAML sign-ins rely on their identity provider's authentication and MFA instead.
The Console currently registers one passkey. To replace it, switch to email codes in a password-authenticated session, then choose Passkey and register the replacement. Use email codes if your browser does not support passkeys.
Signing requests with SHA-384
Signature authentication proves that a request comes from someone who holds your secret. New Auth Keys for ordinary API requests default to HMAC-SHA384. Each key has its own algorithm setting. Use SHA-384 for new API request signatures rather than SHA-1. Smart CDN URL signatures use SHA-256 instead. Smart CDN-enabled keys accept only a SHA-256 restriction or no per-key restriction; they do not inherit the ordinary key's SHA-384 default. Once a key has an algorithm restriction, API requests signed with another algorithm are rejected. Keys without a restriction accept SHA-1, SHA-256, and SHA-384 for API requests. The authentication docs describe the full signing contract.
Use a separate key for Smart CDN signing. Enabling Smart CDN on an existing SHA-384-restricted key without explicitly choosing a compatible restriction clears that restriction, allowing SHA-1, SHA-256, and SHA-384 for API requests again. Choose a SHA-256 restriction if you enable Smart CDN on an existing key. These API request settings do not change Assembly Notification signatures.
Our Node SDK signs with SHA-384 by default; set its
signatureAlgorithm: 'sha256' option for a key restricted to SHA-256. If you sign requests yourself
with SHA-384, prefix the hex digest with sha384:. Here is a small helper for an ordinary
SHA-384 API key that uses only Node's built-in crypto and fetch:
// sign.mjs
import { createHmac } from 'node:crypto'
export async function postApi2(path, fields, key, secret) {
if (!key || !secret) throw new Error('Set your server-side Transloadit credentials')
const expires = new Date(Date.now() + 10 * 60 * 1000).toISOString()
const params = JSON.stringify({ ...fields, auth: { key, expires } })
const hmac = createHmac('sha384', secret).update(params).digest('hex')
const body = new URLSearchParams({ params, signature: `sha384:${hmac}` })
const res = await fetch(`https://api2.transloadit.com${path}`, { method: 'POST', body })
if (!res.ok) throw new Error(`Transloadit request failed (HTTP ${res.status})`)
return res.json()
}
This script uses it to create an Assembly that imports an image and resizes it:
// assembly.mjs
import { postApi2 } from './sign.mjs'
const { TRANSLOADIT_KEY, TRANSLOADIT_SECRET } = process.env
const steps = {
imported: { robot: '/http/import', url: 'https://demos.transloadit.com/inputs/chameleon.jpg' },
thumb: { use: 'imported', robot: '/image/resize', width: 200, height: 200 },
}
const assembly = await postApi2('/assemblies', { steps }, TRANSLOADIT_KEY, TRANSLOADIT_SECRET)
console.log(assembly.ok ?? assembly.error, assembly.assembly_id ?? assembly.message)
Run it on your server with a supported Node.js release and an Auth Key with the
assemblies:write scope:
$ export TRANSLOADIT_KEY=MY_AUTH_KEY TRANSLOADIT_SECRET=MY_SECRET_KEY
$ node assembly.mjs
ASSEMBLY_EXECUTING 1aa00d5b547b…
The initial response means processing has started, not that the thumbnail is ready. Follow the Assembly Status until it completes or fails. For this sample image, successful completion produces a 200×133 thumbnail.
Scoped Auth Keys
A key that can do everything is a liability when it leaks. Every new Auth Key now needs at least one
scope. Prefer area-specific scopes for Assemblies, Templates, Template Credentials, Auth Keys,
billing, queues, or Smart CDN signing. The legacy read and write scopes remain available but
grant broad access. Give each app and environment its own key with only the permissions it needs,
and revoke one without touching the others.
In the Console, go to Credentials and click New Auth Key. The Private image delivery (Smart CDN signing) preset creates a key that can sign Smart CDN URLs but cannot create standalone Assemblies or manage Storage. Choose Custom to tick the scopes yourself. The API offers the same through creating an Auth Key and listing the available scopes.
We check the scope on each call. The key behind these examples can create Assemblies, but not new keys:
// create-key.mjs
import { postApi2 } from './sign.mjs'
const { TRANSLOADIT_KEY, TRANSLOADIT_SECRET } = process.env
const fields = { scope: 'assemblies:write', description: 'my-app staging' }
postApi2('/auth_keys', fields, TRANSLOADIT_KEY, TRANSLOADIT_SECRET)
.then((res) => console.log(res.ok))
.catch((error) => {
console.error(error.message)
process.exitCode = 1
})
$ node create-key.mjs
Transloadit request failed (HTTP 403)
The API returns INSUFFICIENT_AUTH_SCOPE because this operation requires auth_keys:write;
the helper reports the HTTP status without printing the response body. A key with that scope gets
AUTH_KEY_CREATED instead. Treat auth_keys:write as an administrative privilege: it can create
keys with broader scopes, so reserve it for a dedicated, tightly protected key.
The successful creation response also contains the new key's secret,
which this example deliberately does not print. Store it securely when integrating key creation.
Setting can_show_auth_secret during creation permits one later reveal, not unlimited retrieval.
If you run the example with permission to create keys, delete the test key afterward in the Console.
The paperwork
The security page collects what procurement asks for:
- SOC 2 Type II. Our attestation report is available on request under an NDA.
- ISO 27001. Transloadit is ISO/IEC 27001 certified.
- SLA. Our service level agreement is public. It defines Annual Uptime Percentage and Annual Queue Percentage commitments, and it grants service credits when the eligibility and claim requirements in the agreement are met.
For finance teams, the Billing Admin role lets someone change the plan, view billing and usage, and update the billing email and payment method without full Workspace admin rights.
Getting started
You can configure passkeys and Auth Keys in the Console. SAML single sign-on is in early access for Enterprise Workspaces; see our pricing page for plans. To enable SSO, request the SOC 2 Type II report, or walk through a security questionnaire together, email our sales team.