OptionalauthHow long auth tokens issued via b2_authorize_account are valid
for, in milliseconds. The simulator also uses this TTL for upload
authorization tokens issued via b2_get_upload_url and
b2_get_upload_part_url. Defaults to 24 hours (real B2). Tests
that want to exercise the 401/reauth retry path or stale upload
URL handling can lower this and use B2Simulator.advanceTime
to move simulator time past account-token expiry. Upload tokens are
rejected at the exact expiry boundary.
OptionalcustomWhether the simulated account may set custom upload timestamps on
b2_upload_file and b2_start_large_file. Defaults to false, matching
production accounts without the restricted feature enabled.
OptionalminimumThe minimum part size the simulator advertises in b2_authorize_account
responses (apiInfo.storageApi.absoluteMinimumPartSize). Defaults to
5_000_000 to mirror production B2. Lower this in tests that exercise
multipart control-flow branches but don't need realistic part sizes,
because v8 coverage instrumentation pushes 5 MB+ part hashing past 60 s
on the slowest CI runners, which trips vitest's IPC RPC timeout.
OptionalonDiagnostic hook: invoked with any error thrown or rejected by
onWebhookDeliver / onReplicate. Without this, errors thrown by
user-supplied hooks are silently swallowed (intentional: a buggy
hook must not corrupt an otherwise-successful upload), which makes
test debugging hard when a hook quietly stops firing. Register
onHookError to surface what would otherwise be invisible.
OptionalonPluggable hook: invoked after every successful upload on a bucket
configured as a replication source. Receives the source FileVersion
and the destination bucket ID. Tests can register a hook to
verify replication intent without actually copying bytes inside
the simulator.
OptionalonPluggable hook: invoked after every successful upload, copy, or
finishLargeFile on a bucket with a matching event-notification
rule. Tests can register a hook to assert the SDK's webhook
publishing path without spinning up a real HTTP listener.
Receives the freshly-stored FileVersion, the bucket the upload
landed in, and the rule that matched. Returns a promise so async
hook implementations are allowed; the simulator never blocks on it
(errors thrown from the hook are surfaced via bestEffort to
avoid masking the underlying API call's success).
OptionalpartnerWhether the simulated partner administrator has a valid phone number.
Defaults to true; false produces Partner prerequisite failures
such as 403 access_denied or 401 invalid_sms_phone depending on
the endpoint's documented error shape.
OptionalpartnerWhether the simulated partner administrator account is in good standing.
Defaults to true; false produces 403 access_denied on Partner calls.
OptionalpartnerWhether Partner API endpoints should accept issued Partner authorization
tokens. Defaults to true. Set to false to exercise documented
403 access_denied prerequisite failures.
OptionalpartnerWhen true, v3 b2_authorize_account responses include Partner and
Computer Backup suites and issue Partner authorization tokens. Partner
and Backup endpoint calls then require one of those issued tokens, even
when strictAuth is otherwise disabled, so SDK auth-error paths can test
documented 401 responses.
Defaults to false: direct Partner/Backup endpoint tests remain
permissive and accept any non-empty, whitespace-free Partner token without
requiring an authorize call first.
OptionalpartnerComputer Backup API suite capabilities granted by simulator-issued
Partner authorization tokens. Defaults to ['all'].
OptionalpartnerPartner API suite capabilities granted by simulator-issued Partner
authorization tokens. Defaults to ['all'].
OptionalrecommendedThe recommended part size the simulator advertises in
b2_authorize_account responses (apiInfo.storageApi.recommendedPartSize).
Defaults to 100_000_000 to mirror production B2. Lower this when a test
needs to exercise the SDK's "use the recommended size when the caller
omits partSize" default-branch without uploading 100 MB of bytes.
OptionalstrictWhen true, the simulator enforces application-key capability
checks, bucket scoping, prefix scoping, and auth-token expiry on
every request. The default false keeps the simulator permissive
for account/application-key authorization (matching its
long-standing behaviour): any well-formed Basic credential whose
applicationKeyId is not a simulator-created key receives the
implicit master grant, so tests do not have to set up keys with
the right capabilities. Created keys always authorize with their
stored capabilities, bucket scope, name prefix, and expiration;
a wrong or expired created-key secret is rejected.
Upload authorization tokens returned by b2_get_upload_url and
b2_get_upload_part_url are always enforced, regardless of this
option. Upload handlers reject missing, unknown, expired, or
wrong-URL upload tokens in both permissive and strict modes.
In strict mode:
b2_authorize_account still accepts the documented implicit
master credentials test-key-id:test-key and
master-key-id:master-key.bad_auth_token.expired_auth_token.unauthorized.unauthorized.Each test can opt in: new B2Simulator({ strictAuth: true }).
Options for constructing a B2Simulator.