> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parlayx.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Traders and Permissions

> The people who trade, what they can do, and how access is granted and withdrawn.

## What a trader is

A trader is a member of your organization added with the trader role. The trading platform is the only surface they have.

See [Organization](/organization) for roles and what an admin does.

## Adding a trader

An admin adds a trader in two steps, both in the Platform:

1. Add them to the organization as a trader. They can then sign in to the trading platform.
2. Add them to each pod they should trade.

Access is per pod: a trader with no pod can sign in but cannot trade, and removing one pod leaves the others.

## What a trader can do

Two settings an admin controls decide what a trader can do:

| Setting | Set where | Effect |
| - | - | - |
| Pods | On each pod | Which books the trader can see and trade |
| May create API keys | On the trader | Whether the trader can create a key and trade programmatically |

## API keys

A trader who may create keys creates them from the trading platform, one key per pod. The keypair is generated in their browser: ParlayX registers the public half and never sees the private one, which the trader is shown once.

Each key carries one permission, set by your organization: some organizations issue data keys only, others issue data and trade.

A **trade** key is for a trader placing orders. It can:

* **Place orders** in its pod
* **Read its own orders and fills**
* **Cancel its own orders**
* **Read its pod's balance and positions**
* **Read market data**: discovery and the orderbook stream

A **data** key is for a consumer that never trades, such as a data or monitoring
integration. It can:

* **Discover markets** and look one up
* **Subscribe to the orderbook stream**

See [Authentication](/authentication) for the full capability table and how a request is verified.

## Attribution

Every order carries the trader that placed it. That gives you, without any additional work:

* Per-trader position, derived from that trader's own fills
* Per-trader realized and unrealized P\&L
* A complete record of who did what, in which pod, at which venue

See [Portfolio and positions](/portfolio-and-positions).

## Rotate, revoke, remove

| Operation | What happens |
| - | - |
| **Rotate a key** | The trader revokes it and creates a new one from the trading platform. Same trader, same pod, new credential |
| **Revoke a key** | That credential stops working at the front door. The trader stays on the pod and can create another if permitted. An admin can revoke any key |
| **Remove a trader from a pod** | Their access to that pod goes, and its key with it. Their other pods keep working |
| **Remove a trader from the organization** | Their access ends everywhere: every pod, every key, and their sign-in |

> [!WARNING]
>
> Removing a trader does not close their positions. Those positions remain open, and remain the pod's. Manage them from the Platform or through another trader in the pod.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.