Skip to main content
Changed in v0.11.0. getConfig returns the decoded JSON value. The type mapping is:

​
Why some integers are bigint

Because a number cannot hold every integer a config value might carry. A JavaScript number is an IEEE-754 double, and its mantissa is 53 bits wide. Above 2^53 JSON.parse starts rounding, and it does so silently: a snowflake id, an amount in minor units, a nanosecond timestamp all come back as a different number, with nothing anywhere reporting a problem.
Since Node 22 the fix needs no dependency. The JSON.parse reviver receives the original text of each primitive (context.source), so the SDK can see that a value did not round-trip and hand back an exact bigint instead:
The decoding is lossless rather than uniform. A value stays a number whenever a number can represent it exactly, and becomes a bigint only when it could not. Ordinary arithmetic in your code is untouched; the values that used to be wrong are now correct. Making every number a bigint would have been simpler to describe and would have broken arithmetic everywhere for the sake of the rare large integer. Note that JSON.stringify refuses a bigint. If you serialise a config value straight into a response, either use getConfigRaw or convert explicitly.

​
getConfigRaw

Returns the value as JSON text, or undefined when the key is absent:
This is the escape hatch for a value that needs a numeric type the SDK does not choose for you - a decimal library, for instance. Integers are exact here at any magnitude. A fractional literal carrying more precision than a double can hold is already rounded by the time it reaches you, so store such values as strings if you need them digit-for-digit. A monetary amount is best stored either as a string or as an integer number of minor units, and the latter is now exact at any size.

​
Why not getConfigAs<T>()

The Go SDK has one, because encoding/json had already destroyed the value by the time the caller saw it, so a typed accessor that decodes from the original bytes buys real safety. In TypeScript a generic accessor is only a cast - getConfigAs<number>('x') would assert a type without checking anything - so it would add API surface and no guarantee. getConfigRaw plus your own parser is the honest version of the same thing.

​
Reading everything at once

A public (wxp_) key receives the same configs and flags a secret key does. What it does not receive is secrets, which are absent from the sync response entirely.

​
Next