> ## Documentation Index > Fetch the complete documentation index at: https://docs.trdrs.co/llms.txt > Use this file to discover all available pages before exploring further. # Register an account > One registration, four statuses, a 30-day window — and no password field anywhere in it. A registration is a small, deliberately powerless object: it says an account exists at your venue and names the trader who should see it. It carries no credential, grants no access, and commits your firm to nothing. That is what makes it safe to write straight from a provisioning pipeline. Everything here runs with your partner key against `/api/partner/` routes. [Create an account registration](/api-reference/connect/create-an-account-registration) takes the trader's trdrs sign-in `email` — the only required field — plus the venue `accountNumber` when you know it and the `venueLogin` name you issued. ```bash theme={null} curl -X POST "$TRDRS_API_BASE_URL/api/partner/connect/accounts" \ -H "Authorization: Bearer $TRDRS_PARTNER_KEY" \ -H "Content-Type: application/json" \ -d '{ "email": "trader@example.com", "accountNumber": "PA-4821-07", "venueLogin": "jsmith-apex" }' ``` `accountNumber` is at most 40 characters and `venueLogin` at most 60. The response is the registration as created: its `id`, the `connector` and `system` it resolved to, `status` `pending`, a `createdAt`, an `expiresAt` 30 days out, and a null `linkedAt`. The trader finds it when they sign in with that same `email`. The connect step pre-fills your firm and system; the trader types their own credential to finish. The route is idempotent per `(email, accountNumber)`. Re-posting a pair you already registered refreshes the 30-day expiry rather than creating a second handoff — so a pipeline that crashed mid-batch can simply re-run, and a trader who let their window lapse can be given a fresh one with the same call. Registering a *different* account for the same trader is a different pair, so it is a new registration. One registration is one account handoff; never edit an old one into a new meaning. [List your registrations](/api-reference/connect/list-your-registrations) returns every registration your firm has made, newest first, with `firm` naming you. ```bash theme={null} curl "$TRDRS_API_BASE_URL/api/partner/connect/accounts" \ -H "Authorization: Bearer $TRDRS_PARTNER_KEY" ``` Scope is your own firm and nothing else — the firm is resolved from the key, and there is no parameter that widens it. This is the read to reconcile against your own onboarding records: who you invited, and who actually arrived. [Revoke a pending registration](/api-reference/connect/revoke-a-pending-registration) takes the `id` as a query parameter — a refund, a reassignment, a mistake. ```bash theme={null} curl -X DELETE "$TRDRS_API_BASE_URL/api/partner/connect/accounts?id=reg_7f3ka9" \ -H "Authorization: Bearer $TRDRS_PARTNER_KEY" ``` A missing `id` is a `400`. A `404` means there is no pending registration with that id — it is already linked, already revoked, or not yours, and the three are answered identically so this surface never confirms another firm's registration ids. ## What each status means | `status` | What it means | What put it there | | --------- | --------------------------------------------------------------------- | ---------------------------------------------------------------- | | `pending` | Created and waiting for the trader. | You called the create route. | | `linked` | The trader signed in and linked the account. `linkedAt` carries when. | The trader completed the connect flow with their own credential. | | `revoked` | The pending handoff was taken down. | You called the revoke route while it was still `pending`. | | `expired` | The 30-day window ran out with nobody linking it. | `expiresAt` passed. | Only `pending` has more than one exit. A linked registration cannot be revoked: the trader holds the account through a credential your firm never had, so there is nothing on this surface to take back. Ending that relationship is a matter for your venue, not for this API. ## Why there is no password field The credential moves from your firm to the trader through your own onboarding, and from the trader to the engine's encrypted vault when they submit the connect form. It never travels through this API and never sits in a trdrs email — trdrs sends no customer handoff message at all, so notifying the trader and delivering their venue credential is your firm's job, in full. Two consequences worth building around: * **`venueLogin` is a label, never a secret.** It is the login *name* you issued, so the connect screen can show the trader which login to authenticate as. Sending anything password-shaped in it puts a secret somewhere it does not belong. * **The retired `handover` field is rejected, not ignored.** If a pre-partner test client still sends it, the request fails rather than quietly dropping a field you thought was doing something. ## The refusals | Status | When | | ------ | --------------------------------------------------------------------------------------------------------------- | | `400` | Malformed input on create, or a missing `id` on revoke. | | `401` | The bearer is not a partner-scoped key for an active partner firm. A tenant key is refused here just as firmly. | | `404` | Revoke only: no pending registration with that id — already linked, already revoked, or not yours. | ## Where to go deeper * [Follow registrations](/guides/handle-registration-events) — `registration.linked` and `registration.revoked` on your own server. * [Connect](/partner-platform/operator-concepts/connect) — the handoff end to end, and why it splits the way it does. * [Two ways in](/guides/account-paths) — this path beside the other one, and when a firm uses each. * [Read your usage](/guides/read-your-usage) — what a linked account costs, and how to reconcile it. * [Keys](/partner-platform/overview/keys) — why a partner key cannot trade or read a trader's account.