Skip to main content
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.
1

Create the registration

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.
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.
2

Register the same account again, on purpose

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.
3

List your registrations as the audit view

List your registrations returns every registration your firm has made, newest first, with firm naming you.
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.
4

Revoke one that is still pending

Revoke a pending registration takes the id as a query parameter — a refund, a reassignment, a mistake.
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

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

​
Where to go deeper

  • Follow registrations — registration.linked and registration.revoked on your own server.
  • Connect — the handoff end to end, and why it splits the way it does.
  • Two ways in — this path beside the other one, and when a firm uses each.
  • Read your usage — what a linked account costs, and how to reconcile it.
  • Keys — why a partner key cannot trade or read a trader’s account.