Time: 10 minutes | Level: Beginner
You will learn: Where Slack secrets should live, and what to do if one leaks.
You will need: Your webhook URL or bot token from Step 1.
A Slack webhook URL or bot token is a key. Whoever holds it can post into your workspace as your app, and with a bot token they may be able to read user details as well. So it is worth spending a few minutes to store these carefully.
This page is deliberately practical: what to do, what not to do, and how to recover if something leaks.
The golden rules
- Never hard-code a secret in a script file. Script files are readable by anyone with File Cabinet access, get copied into sandboxes, and end up in version control.
- Never paste a secret into a chat, ticket or screenshot.
- Give each purpose its own webhook or token where you can. If one leaks, you replace one thing.
- Only request the Slack permissions you need.
- Know how to rotate. Practise it once, so it is calm when you need it.
Where secrets can live in NetSuite
| Option | Effort | Protection | Comment |
|---|---|---|---|
| Hard-coded in the script | None | Poor | Please do not |
| Script parameter (text) | Low | Basic | Fine for a webhook in a sandbox or low-risk channel. Visible to anyone who can view the deployment |
| A locked-down custom record | Medium | Good if permissions are tight | Handy when several scripts share one token |
| API Secrets (Setup > Company > API Secrets) | Medium | Best | Values are stored securely and not shown in clear text after saving |
A sensible path
- Sandbox and testing: a script parameter is fine.
- Production: use API Secrets for the bot token and signing secret, and restrict who can view or edit the script deployment.
Oracle’s help topics on API Secrets and secure strings describe the exact way to reference a stored secret from N/https and N/crypto. Those method details have changed between releases, so read the current help page instead of trusting a blog post (including this one) for the precise syntax.
Step-by-step: lock down a parameter-based setup
If you are keeping the webhook in a script parameter for now, do at least this:
- Go to Customization > Scripting > Script Deployments and open your deployment.
- On the Audience subtab, limit the roles that can run it.
- Make sure only administrators and named developers have the permissions to view and edit scripts (Lists > Customization style permissions: SuiteScript, Script Deployment).
- Check that the sandbox copy uses a test webhook pointing at a test channel, not production. After a sandbox refresh, NetSuite copies your parameters over, so it is easy to alert real people from a test system by accident. Make this part of your refresh checklist.
Step-by-step: use an API Secret (recommended for production)
- Go to Setup > Company > API Secrets (you need the right permission; ask your administrator if you do not see it).
- Click New and give the secret an ID and a friendly name such as
Slack Bot Token. - Paste the token value and save. From now on the value is hidden.
- In your script, reference the secret by its ID following the pattern in Oracle’s current documentation for
N/httpssecure strings. - Repeat for the signing secret if you use interactive features.
What to do if a secret leaks
Do these in order, and do not be embarrassed, it happens to everyone.
- Revoke it at the Slack end. For a webhook, remove it under Incoming Webhooks in your app settings. For a bot token, use Reinstall to Workspace or revoke tokens in the app settings.
- Create a replacement and update NetSuite.
- Check the Slack audit logs or channel history for anything that should not be there.
- Find out how it leaked (a screenshot, a support ticket, a script in a public repository) so it does not happen again.
Careful with what you send, too
Secrets are not the only sensitive thing. Before you put NetSuite data in a Slack message, ask:
- Who is in this channel today, and who might be next month?
- Is it acceptable for a contractor or a guest to see this?
- Could I send a link to NetSuite instead of the data itself?
A good default is to include an order number, a customer name and a link, and to leave out anything like bank details, personal addresses, tax IDs or confidential pricing.
Quick checklist
- β No secrets in script files
- β Separate webhooks for sandbox and production
- β Bot token and signing secret in API Secrets for production
- β Script deployments restricted to the right roles
- β A note somewhere about how to rotate each secret
- β Messages contain links, not sensitive details
What is next
With your credentials tucked away, let us make the messages look good. Step 4 introduces Block Kit for tidy, professional-looking alerts.