module function · N/https
createSecretKey()
https.createSecretKey(options)
Creates a key for the contents of a credential field.
- Implementation
- Not started
- Design
- Open for proposals suggest how it should read
A
suitescript api
1https.createSecretKey({2 guid: /* string */,3 secret: /* string */,4 encoding: /* https.Encoding, optional */5});| Parameter | Type | Required | Description |
|---|---|---|---|
| options.guid | string | A GUID used to generate a secret key. Use Form.addCredentialField(options) to generate a GUID. This parameter is not required if you use the secret parameter. You cannot use both the options.guid parameter and secret parameter in combination. The GUID can resolve to either data or metadata. | |
| options.secret | string | The script ID of the secret used for authentication. You can store secrets at Setup > Company > API Secrets. For more information, see Secrets Management . This parameter is not required if you use the options.guid parameter. You cannot use both the options.guid parameter and secret parameter in combination. | |
| options.encoding | https.Encoding | optional | Specifies the encoding for the Secret Key. |
B
mynt syntax
No Mynt syntax yet.
Nothing in the language compiles to https.createSecretKey(options) today. How should it read?
C
community proposals
Competing syntax for createSecretKey, from GitHub Discussions. Select two or more to compare them side by side.
Loading proposals from GitHub…
D
suggest an alternative
Write the Mynt you wish you could write.
A good proposal shows the syntax, the SuiteScript it should become, and argues for it: why it is clearer, how it fits the rest of the language, what it makes harder.
- Clarity. Does it say what happens, without ceremony?
- Consistency. Does it read like
load,saveandRef[field]? - Expressiveness. Does it cover the cases people actually write?
- Honesty. Does it hide a NetSuite cost, such as governance, that a reader should see?