Before you build
Prerequisites and ownership
The automation should connect accounts the client already controls. Confirm the following before implementation:
- Slack workspace admin or app-management access
- A Slack app, signing secret, and public HTTPS request URL
- A bot token with only the OAuth scopes required to open the flow and post its result
- An Arcads workspace with authenticated external API access
- An approved script or brief, actor or template, output settings, and enough generation credits
- A named owner for approvals, failures, and final asset review
Keep Slack and Arcads credentials in server-side secret storage. Never paste them into a channel, modal field, source repository, analytics event, or operational log.
Reference architecture
Seven stages from request to result
Create the Slack entry point
Use a slash command or shortcut to open a modal. Collect the client, approved script or brief, output format, actor or template, and the requester. Keep optional fields visibly optional.
Verify the request before parsing it
Read the raw HTTP body, calculate Slack’s signing-secret HMAC, compare signatures safely, and reject stale timestamps. Only then parse and act on the payload.
Validate the production contract
Require the agreed fields, an approved generation recipe, usage rights, and an explicit approval state. Return a useful error before spending any generation credits.
Prevent duplicate jobs
Create an idempotency key from the Slack request or interaction ID. Store it before submitting and return the existing run when Slack retries the same request.
Submit one Arcads job
Call the authenticated external API from the server, using the approved script, actor or template, and output settings. Store the Arcads run ID beside the Slack context.
Track the asynchronous run
Acknowledge Slack quickly. Poll the run-status endpoint or consume an approved webhook outside the original request, with a timeout and bounded retry policy.
Return the result to Slack
Post the final asset link to the originating channel or thread. On failure, send an actionable state and log the external run ID without exposing a token or credential.
Security boundary
Verify first. Spend credits second.
Slack signs incoming requests with a workspace app’s signing secret. Verification must use the raw request body before parsing, the request timestamp, and the provided signature. Reject an invalid signature and reject a timestamp older than five minutes to reduce replay risk.
Store the signing secret, Slack bot token, and Arcads credential only on the server. Grant the Slack bot the least-privilege OAuth scopes needed for the agreed flow, and never return credentials in a response or failure message.
Primary references: Slack request signing, Slack interaction handling, Arcads API guide, and Arcads MCP guide.
Definition of done
Acceptance tests for the pilot
- A valid signed request opens the agreed collection flow.
- A bad signature or request older than five minutes is rejected.
- A missing required field creates no Arcads job and consumes no credits.
- Replaying the same Slack interaction creates no second job.
- An accepted request records and exposes its Arcads run ID.
- A successful run posts a usable result link to the originating Slack context.
- A failure, quota error, or timeout returns an actionable state without exposing credentials.
- The run log contains request ID, run ID, status, timestamps, and result URL—not secrets or unnecessary brief content.
Common questions
Slack–Arcads automation FAQ
Does this automation move money?
No. It submits an approved production job and reports its state. Billing, card charges, refunds, and payouts remain outside the pilot.
Who pays for Arcads usage credits?
The client owns the Arcads workspace, credentials, plan, and generation credits. FlowPatch does not resell or bundle credits.
Does the workflow write ad copy?
Not by default. The safe pilot starts from an approved script or brief. Copy generation can be scoped separately with its own review gate.
Can the same pattern use another video-generation tool?
Yes, when that platform provides authenticated API access for job creation and status retrieval. The request contract and security boundaries still apply.
Does a single-workspace pilot require Slack Marketplace distribution?
No. An internal Slack app can be installed to one approved workspace. Marketplace distribution is a separate product and compliance decision.