Migreren vanuit Beta

Je bestaande API-keys worden niet ingetrokken of opnieuw uitgegeven. De inloggegevens, rechten en Account-koppeling blijven volledig behouden. Bestaande calls waarbij geen account_id wordt meegegeven, blijven werken op het primaire Account van de Organisatie. Controleer hoe je integratie een ander Account selecteert en opname-responses verwerkt.

Selecteer een specifiek Account wanneer nodig

Als account_id niet wordt meegegeven, voert een privéverzoek bewerkingen uit op het primaire Account:

Om bewerkingen uit te voeren op een specifiek Account, geef je account_id mee als queryparameter in de URL:

Geef het mee in de URL, niet in de request body. Een expliciete account_id heeft voorrang op het primaire account als fallback. Dit breidt de Account-koppeling of rechten van de key niet uit.

Lees de nieuwe opnamereactie

WithdrawFunds geeft approval_request_id terug samen met refid:

• Een refid betekent niet langer dat de opname is voltooid. Het bedrag wordt vergrendeld op het bron-Account zodra het verzoek wordt ingediend, en wordt pas verwerkt nadat het verzoek is goedgekeurd.
• approval_request_id is de referentie voor de goedkeuring waar de opname op wacht. Sla deze op bij je eigen administratie.
• Opnames die wachten op goedkeuring verschijnen niet in WithdrawStatus. Een verzoek dat wordt afgewezen of verloopt laat geen opnamerecord achter, dus het ontbreken van een vermelding in WithdrawStatus betekent nooit dat een opname niet is ingediend.

Automatisering die een refid als bewijs van voltooiing beschouwt, rapporteert opnames als verwerkt terwijl ze nog in de goedkeuringswachtrij staan. Zie API keys voor het volledige model.

Na de conversie beschikt je Organisatie over twee sets standaard bouwstenen.

Workflow Profiles

Een Workflow Profile bepaalt wat een Lid mag doen in elke beheerde workflow. Elk Lid heeft er precies één.

Account Roles

Een Account Role bepaalt wat een Lid mag doen op je Accounts. De standaardrollen gelden voor alle huidige en toekomstige Accounts, zodat een Lid met Trade all ook kan traden op een Account dat je morgen aanmaakt.

Standaardprofielen en -rollen groeien mee met het product: wanneer een nieuwe workflow wordt toegevoegd, krijgen Members die er een hebben automatisch het bijbehorende niveau. Zie Rollen, profielen en machtigingen voor het volledige model.

Als de machtigingen van een Member niet overeenkomen met een standaardprofiel, krijgt die Member een rol met precies de machtigingen die hij al had. Members met identieke machtigingen delen één rol, zodat je Organisatie aanzienlijk minder rollen dan Members heeft.

Deze rollen krijgen de naam van het label dat je bij de Member had ingevuld, dus een Member met het label "Trader" krijgt een rol met de naam trader. Members zonder label krijgen de rol migrated-role. Elke rol heeft een badge migrated, wat betekent dat de naam automatisch is gegenereerd en je die zelf kunt wijzigen.

Waarom je "Admin"-Members niet in het Admin-profiel staan

Het Beta-label "Admin" gaf iemand de mogelijkheid om te bekijken, te initiëren en goed te keuren, maar niet om eigen verzoeken af te ronden zonder een tweede goedkeuring. Het Admin-profiel omvat die mogelijkheid wel: het Execute-niveau.

In plaats van dit automatisch toe te kennen, worden Members met het oude label geplaatst in een rol genaamd beta-admin met precies de machtigingen die ze al hadden. Ze naar Admin verplaatsen is een enkele toewijzing, wanneer je daar klaar voor bent.

De Owner wordt ingedeeld op het Admin-profiel, behoudt alle bestaande rechten en krijgt nieuwe workflows automatisch toegewezen. De Owner heeft ook Read all, dat niet kan worden verwijderd.

Als je de rechten van de Owner bewust had beperkt, blijft die keuze behouden: de Owner wordt omgezet naar een rol met de werkelijke rechten, net als elk ander Member.

• Alle rechten die elk Lid had, worden volledig overgedragen.
• API Key-inloggegevens, rechten en Account-koppeling blijven behouden.
• Tegoeden, Accounts en Account-eigendom blijven ongewijzigd.
• Lopende goedkeuringsverzoeken worden voortgezet, en je beleidsregels, goedkeuringsdrempels en de instelling "altijd goedkeuring vereisen" blijven ongewijzigd.
• Identiteitsverificatie blijft ongewijzigd en niemand hoeft opnieuw in te loggen of opnieuw uitgenodigd te worden.
• Alleen Accounts die bij je Organization horen, worden omgezet. Een recht op een Account buiten de Organization blijft ongewijzigd.

Calls zonder account_id gebruiken het primaire Account van de Organization. Om te rapporteren over een ander Account in de Account-koppeling van de Key, geef je de account_id van dat Account mee op de URL. Zie "Kies een specifiek Account wanneer nodig."

De call heeft een verzoek aangemaakt en het bedrag geblokkeerd op het bron-Account. Verrekening vindt plaats na goedkeuring. Volg het verzoek via de approval_request_id die de call retourneert, of zoek het op op de pagina Verzoeken. Zie Overboekingen en opnames.

Members van wie de rechten niet overeenkomen met een standaardprofiel krijgen elk een aparte rol die hun toegang behoudt; twee Members worden alleen samengevoegd op één rol als hun rechten identiek zijn. Members aan wie je verschillende labels had gegeven, blijven op afzonderlijke rollen staan, ook als hun rechten overeenkomen, omdat de labels erop wijzen dat het onderscheid bewust was. Rollen die je niet nodig hebt, kun je samenvoegen door de Members opnieuw toe te wijzen en de lege rol te verwijderen.

Members die de Organisatie beheren – teamtoegang, Accounts of API-keys – worden toegewezen aan Alles lezen, omdat je een Account moet kunnen zien om het te beheren. Is dat ruimer dan gewenst, vervang Alles lezen dan door een Account Role die beperkt is tot de specifieke Accounts die ze nodig hebben.

Nee. De conversie is eenrichtingsverkeer. Alles wat de conversie oplevert is achteraf bewerkbaar, zodat je elke toegangsstructuur opnieuw kunt inrichten met profielen en rollen.