Skip to main content

This is the shortest first-result path: get key access, activate a device, add Runtime Kit, read named data, and send one action request.

You are building the first screen of a product. It needs one piece of named data and one button that asks Bitfield to do work.
1

Create account access and activate the device you are using.

→
2

Add the public app-facing package.

→
3

Render named data and call a named target.

The first working shape is small: render one prepared value and send one action request without importing private package setup.

​
Prerequisites

NeedWhy
Bitfield account accessThe account portal owns key access and runtime/device management.
One activated runtime identityRuntime Kit runs against an account/device path, not a random anonymous install.
A JavaScript app surfaceThe current public examples use the JavaScript Runtime Kit and React hook.
A data name and action nameApp code reads named named data and sends requests to named targets.
If you do not have key access yet, do Get your key first.

​
1. Get your key and activate this device

Open account.bitfield.so, create or open your account, confirm email if needed, and activate the device you are using.Your account portal is where you manage runtime identities, replace a device, recover access, and find the current install instructions for your account.

​
2. Add Runtime Kit

Runtime Kit is the customer-facing package that app code talks to. Your account portal gives the current install instructions for your account and environment.The public JavaScript surface is intentionally small:
import { sendRequestToBitfieldTarget } from '@bitfield/runtime-kit';
import { useBitfieldData } from '@bitfield/runtime-kit/react';

​
3. Read named data in React

useBitfieldData(...) reads materialized data that Runtime Kit has already made available to your app.
import { useBitfieldData } from '@bitfield/runtime-kit/react';

export function InboxCount() {
  const inbox = useBitfieldData<{ id: string }[]>('inbox');

  if (inbox.loading) return <span>Loading</span>;
  if (inbox.error) return <span>Could not read inbox</span>;

  return <strong>{inbox.data?.length ?? 0}</strong>;
}
The screen shows an inbox count when the named data is available. The component owns loading, error, and success rendering. It does not decide how Bitfield stores or prepares the data.

​
4. Send a request

sendRequestToBitfieldTarget(...) sends opaque request data to a Bitfield target and returns the reply. Your app does not need to know how the target is mounted.
import { sendRequestToBitfieldTarget } from '@bitfield/runtime-kit';

const reply = await sendRequestToBitfieldTarget({
  target: 'inbox.refresh',
  payload: { reason: 'first-run' },
});
The app asks the named target to do work and waits for a reply. The button does not import the target implementation.
The app surface stays narrow on purpose. The product can gain new storage paths, packages, devices, or slots without making every React component learn a new API.

​
What you just built

You did not build the whole product. You built the public app-facing shape:
PieceWhat it proved
Account and deviceRuntime Kit is attached to your account path.
useBitfieldData(...)React can read prepared product data by name.
sendRequestToBitfieldTarget(...)App code can ask a named Bitfield target to do work.
Loading/error/success UIThe surface can handle real runtime states instead of assuming data is always there.

​
Common failures

SymptomLikely causeFix
You do not know where to get the keyAccount path was skippedOpen Get your key
The component stays loadingDevice/account path or data name is not readyCheck account activation, then read Runtime Kit troubleshooting
The read returns no dataThe data name does not exist yetFollow Package to screen
The action request failsThe action name or payload contract is wrongRead Send a request
Generated code imports a deep Runtime Kit fileIt crossed the public files and namesUse only the imports shown on this page

​
Next

Last modified on May 11, 2026