First steps

When you open a new workspace, its Overview starts with a checklist of first steps. Each step ticks itself when the portal sees it done in your workspace's own data, so you don't have to mark anything. Steps stay done after their traffic ages out of the 7-day views.

Step	Done when
Request access	RND approved your request and created the workspace
Sign in	You're signed in to the portal and a member of the workspace
Create an app	Your organisation has at least one app
Get credentials	One of your apps has a producer connection in this workspace with its client secret issued, a consumer connection has its pull-API client secret, or the workspace has an active consumer connection
Dry-run a message	Someone in the workspace ran a message through the Playground
Publish a first message	The gateway accepted a message in this workspace
See it in the timeline	Someone in the workspace opened a story that has messages

Each step links to the page where you do it (Get credentials links to both Apps and Consumer connections) and to its section below. Press Hide to put the checklist away; the Overview then shows one line with your progress and Show the checklist. Hiding is remembered in this browser only.

A publisher's workbench is for grading in-house apps, not for publishing, so its checklist ends differently: after Get credentials come Grade it with a test run (a complete test run in the workbench) and Make a results statement (a results statement made there).

The whole-bus view that RND admins use has no checklist.

Sign in

Sign in with the temporary password from your approval email, choose your own password and set up an authenticator app, then accept the invitation to your workspace. See Your workspace in the portal.

Create an app

An app is the system that publishes or reads messages: your NCS, a graphics renderer, a skill executor. Apps belong to your organisation and show on the Apps page. Developers, admins and owners create them there with New app. See Credentials.

Get credentials

To publish, connect a producer app to the workspace on the Apps page, choosing the system_ids it stamps and the message types it sends. You get its client id (the connection id, c…) and client secret (sbs_…). The secret is shown once and stored only as a hash, so keep it in your secret store. Rotate or revoke it from the same page. See Credentials.

To read messages, create a connection on the Consumer connections page. It gets its own queue, and Get client secret gives it a client id and secret for the HTTPS pull API. See Consumer connections.

Dry-run in the Playground

Open the Playground, load an example or paste your own message and press Validate. The gateway checks it exactly as it would a real publish, against your workspace's story state, and stops before anything is stored or sent. Every rule in the verdict links to its page in the rule reference.

Publish a first message

Publish from your own client: get a token from the token service, then post the message to your workspace's route. See Token service and workspace API.

Or, to try the whole path first, publish from the Playground:

1. Under Send as, choose the app to publish as. The examples then carry its system_id.
2. Dry-run the message until the verdict is Would be accepted. The dry run checks the app's grants too.
3. Under Publish for real, give the app's client secret. If you connected the app or rotated its secret in this browser tab, the Playground already has it, shown masked (sbs_••••••); otherwise paste it.
4. Press Publish for real. The verdict is the gateway's real answer: accepted messages go to your workspace's topic, to your consumers and to the story timeline.

What happens to the secret: the portal uses it for this publish to get a token from the token service, the same way your own client does. It then posts the message to your workspace's route with that token. The portal server never stores, logs or shows again the secret or the token. A secret you paste is cleared from the form after each attempt. A secret the portal showed you when you connected the app or rotated its secret stays in that browser tab's memory, never in its storage, until you reload the page or sign out; if the token service refuses it, the tab forgets it and asks you to paste the current one. The token service and the gateway make every check they make for your own client. Each publish from the Playground is recorded in your workspace's audit log, without the secret, the token or the message.

Who can publish from the Playground:

• Developers, admins and owners of the workspace. Viewers can dry-run only.
• As the workspace organisation's own apps. In a publisher house, that means the publisher's own apps: a vendor's connection and its secret stay the vendor's, and the Playground doesn't offer them.
• With a producer connection and its client secret in this workspace. A consumer connection's pull-API secret can't publish.

Publishing the same message again is safe: the bus answers a message it has already accepted as a duplicate, by its message_id.

See it in the timeline

Open the Story timeline, choose your story and follow its messages in order. The timeline keeps 7 days. A message without a story_id is filed under the story its correlation_id belongs to.

Known limits

• Publish for real is available only on environments where client secrets are issued in the portal.
• Reading has no Playground step: read with the HTTPS pull API or, with an AWS reader role you register, with AWS credentials.