Native site access settings

Checked against the product’s code on 7 November 2026.

EmDash’s Users and access settings remain visible on a Praxis site. Use your Praxis account’s Team controls to manage the site’s people and roles.

Users and signup domains

The native user screen points to the Praxis account for role management. Use Your team to invite, change access or send recovery. A user’s existing login is separate from the byline used to credit content.

1. In the site admin, open Settings.
2. Under Security Settings, choose Self-Signup Domains.

Here, Allowed Domains lets people at a domain sign up without an invitation. A new signup receives the chosen Default Role, up to Editor. To give someone Admin access, invite them from Team in your Amadalis account. Only an Admin can add a domain rule. Removing a rule later does not remove the people who already joined through it.

An older rule may still show Default role: Admin. New signups under it join as Editor; the stored rule and existing people’s roles are not changed. While an enabled rule above Editor remains, signing in through another provider is refused. It is also refused if the rules cannot be read.

Review the domain, role and confirmation before saving. A team signup rule is separate from public shopper registration under Commerce > Customer identity.

Personal API tokens

The API is the site’s interface for software requests. On a Praxis site, a personal token can read published content and drafts within its scopes and the token owner’s current role, but any change made with that personal token is refused. A token that lists write permission still cannot bypass that restriction. Reads with a personal API token must also pass the team’s API token checks.

1. In the site admin, open Settings.
2. Open API Tokens to inspect your personal tokens.

Create a token for reading

Create the token in your own site session. Keep its value out of chat and pictures.

1. Choose Create Token to open the form.
2. Enter a purpose you will recognize in Token Name.
3. Under Scopes, select Content Read for content entries. Add Media Read or Schema Read only if your software needs those reads.
4. Choose Expiry.
5. Choose Create Token. A Token created message names the new token.
6. Use Copy token.
7. Save the value securely before Dismiss. It will not be shown again.

The token still follows the read-only, role and team-rule limits on this page. To retire one, use the API token requests; revocation has no automatic Undo. The copilot cannot create the token for you.

The copilot can list and revoke supported personal tokens. Revocation requires approval and has no automatic Undo. This does not provide a general external automation endpoint for agents to publish without review.

New login rules can stop an older key from reading content.

Where your team has rules, personal API tokens and OAuth access tokens must use the allowed network addresses. A holder who has a team membership must have active access. If two factor authentication is required, the holder must have it turned on in their Amadalis account, including for a token created before the rule. A team with no rules is unchanged.

A holder with no team membership still follows the allowed-address list. If two factor authentication is required, only a verified Amadalis identity whose account belongs to this site can pass that check without a team membership. Otherwise, ask the site’s owner for an invitation.

Limits. Session lifetime and idle timeout do not apply to tokens. While the records can be read, changes to rules, membership and two factor status are picked up within 30 seconds. If a read fails, the site can use an answer read within the last five minutes. Without a recent rules answer, it refuses with 503 if the last known policy has a rule or that record cannot be read. A team with no recorded policy or no last known rules can continue. If required membership or two factor information cannot be read and has no recent answer, the request is refused with 503. The response says “We could not check your team’s sign-in rules; try again in a minute.” The retry time is one minute.

These refusals return 403 before the requested action runs:

What needs attention	What the response says
Network address	“Your team allows API tokens on this site only from approved network addresses. Connect from your office or VPN, or ask an admin of your team to add this address.”
Team access	“Your access to this site has been turned off, so this API token no longer works. Ask the site’s owner if that’s unexpected.”
Two factor authentication	“Your team requires two-factor sign-in, so this API token stops working until you turn on two-factor in your Amadalis account.”

A token whose own scopes do not allow a request can receive a permission refusal before these team messages. Issuing or refreshing an OAuth token checks the network rule; membership and two factor are checked when that access token is used. These rules do not change SCIM provisioning tokens or remote-erasure credentials.

Review a device code from your terminal

Use this only for an existing code from a terminal you trust. Keep your own site session open; a staff support session cannot authorize a device.

1. Open the authorization link supplied by that terminal in your signed in browser.
2. On Authorize Device, enter its Device code.
3. Read This device is requesting permission to use: and any Also requested, but not available to your role: list.
4. Choose Authorize only if you recognize the code and intend that access. Otherwise choose Deny before approval.
5. When Device authorized appears, return to your terminal.

An expired code asks you to restart sign in from the terminal. An invalid or used code cannot be approved again. If your role permits none of the requested permissions, Authorize stays unavailable.

This screen has no Undo. Keep the token and team-rule limits above; authorizing an existing code is not a promise of a general external publishing agent.

Passkeys and sign in

EmDash’s native security screen includes passkey records. The copilot can list supported records and request deletion with approval; deletion has no automatic Undo. The copilot cannot add a passkey.

To use the native passkey screen:

1. Open Settings in the site admin.
2. Open Security.
3. Use Passkeys there to add a passkey when the native screen offers it.

On hosted Praxis, use Open admin → from your account for team entry. Native email sign in handoffs are refused in favor of that account flow. Do not rely on a native security screen to replace Account Security or its actual session policy scope.