Overstappen van Bèta

Je bestaande API-sleutels worden niet ingetrokken of opnieuw uitgegeven. Hun inloggegevens, machtigingen en accountkoppeling worden allemaal overgenomen. Wat er verandert, is hoe je code aanvragen adresseert en antwoorden leest.

Selecteer een account bij elke aanvraag

Een organisatie-API-sleutel dekt een of meer accounts en heeft geen standaardinstelling, dus elke privéaanvraag moet aangeven op welk account deze van toepassing is. Geef account_id door als een queryparameter in de URL, niet in de aanvraagbody:

Dit geldt voor zowel traden, saldo- en grootboekquery's, order- en trade-geschiedenis als exports en de verplaatsing van geldmiddelen.

Lees het nieuwe opname-antwoord

WithdrawFunds retourneert approval_request_id naast refid:

• Een refid betekent niet langer dat de opname is voltooid. Het bedrag wordt vergrendeld op het bronaccount wanneer de aanvraag wordt ingediend en wordt pas verrekend nadat de aanvraag is goedgekeurd.
• approval_request_id is de referentie voor de goedkeuring waar de opname op wacht. Sla dit op in je eigen administratie.
• Opnames die wachten op goedkeuring verschijnen niet in WithdrawStatus. Een aanvraag die wordt afgewezen of verloopt, maakt helemaal geen opnamerecord aan, dus afwezigheid in WithdrawStatus betekent nooit dat een opname niet is ingediend.

Automatisering die een refid als bewijs van voltooiing beschouwt, rapporteert opnames als verrekend terwijl ze zich nog in de goedkeuringswachtrij bevinden. Zie API-sleutels voor het volledige model.

Na de omzetting beschikt je organisatie over twee sets standaardbouwstenen.

Workflowprofielen

Een workflowprofiel bepaalt wat een lid kan doen bij elke beheerde workflow. Elk lid heeft er precies één.

Accountrollen

Een accountrol bepaalt wat een lid kan doen met je accounts. De standaardrollen dekken alle huidige en toekomstige accounts, dus een lid met 'Alles traden' kan traden op een account dat je morgen aanmaakt.

Standaardprofielen en rollen houden gelijke tred met het product: wanneer een nieuwe workflow wordt toegevoegd, krijgen Leden die er een hebben automatisch het juiste niveau. Zie Rollen, profielen en toestemmingen voor het volledige model.

Wanneer de toestemmingen van een Lid niet overeenkomen met een standaardprofiel, worden ze in een rol geplaatst die precies bevat wat ze hadden. Leden met identieke toestemmingen delen één enkele rol, zodat je Organisatie veel minder rollen dan Leden zal hebben.

Deze rollen ontlenen hun naam aan het label dat je naast het Lid had geschreven, dus een Lid met het label “Trader” komt terecht in een rol met de naam trader. Leden zonder label komen terecht op migrated-role. Elk van deze rollen heeft een migrated-badge, wat betekent dat de naam is gegenereerd en door jou kan worden gewijzigd.

Waarom je “Admin”-Leden niet in het Admin-profiel staan

Met het bètalabel “Admin” kon iemand verzoeken bekijken, starten en goedkeuren, maar niet zijn eigen verzoeken voltooien zonder een tweede goedkeuring. Het Admin-profiel bevat die mogelijkheid wel, namelijk het Execute-niveau.

In plaats van dit automatisch toe te kennen, worden Leden met het oude label in een rol geplaatst met de naam beta-admin die precies de toestemmingen bevat die ze al hadden. Ze naar Admin verplaatsen is een eenmalige toewijzing wanneer je dat maar wilt.

De Eigenaar wordt in het Admin-profiel geplaatst, behoudt alles wat hij had en krijgt automatisch nieuwe workflows. De Eigenaar heeft ook 'Alles lezen', wat niet kan worden verwijderd.

Als je de toestemmingen van de Eigenaar bewust had beperkt, blijft die beslissing behouden: de Eigenaar wordt omgezet in een rol met zijn werkelijke toestemmingen, net als elk ander Lid.

• Elke toestemming die elk Lid had, wordt overgenomen.
• API-sleutelgegevens, toestemmingen en Account-koppelingen blijven behouden.
• Saldi, Accounts en het eigendom van Accounts zijn ongewijzigd.
• Lopende goedkeuringsverzoeken gaan door en je beleid, goedkeuringsdrempels en instellingen voor “altijd goedkeuring vereisen” zijn onveranderd.
• Identiteitsverificatie is ongewijzigd en niemand hoeft opnieuw in te loggen of opnieuw te worden uitgenodigd.
• Alleen Accounts die bij je Organisatie horen, worden omgezet. Een toestemming op een Account daarbuiten blijft zoals deze is.

In het verzoek ontbreekt vrijwel zeker account_id. Zonder dit wordt een privé-aanroep niet herleid naar een van de accounts van de sleutel en kan deze een leeg resultaat geven in plaats van een foutmelding. Voeg account_id toe aan de URL en controleer elk eindpunt dat je integratie aanroept opnieuw, niet alleen de eindpunten die zichtbaar zijn mislukt. Zie API-sleutels.

De aanroep heeft een verzoek aangemaakt en het bedrag op het bronaccount vergrendeld. De afwikkeling vindt plaats na goedkeuring. Volg het verzoek met de approval_request_id die door de aanroep is geretourneerd, of vind het op de pagina Verzoeken. Zie Overboekingen en opnames.

Leden wiens machtigingen niet overeenkwamen met een standaardprofiel hebben elk een rol nodig die hun toegang behoudt, en twee leden worden alleen samengevoegd in één rol als hun machtigingen identiek zijn. Leden aan wie je verschillende labels had gegeven, blijven in afzonderlijke rollen, zelfs als hun machtigingen overeenkomen, omdat de labels suggereren dat het onderscheid opzettelijk was. Rollen die je niet nodig hebt, kunnen worden samengevoegd door hun leden opnieuw toe te wijzen en de lege rol te verwijderen.

Leden die de organisatie beheren (beheer van teamtoegang, accounts of API-sleutels) worden in 'Alles lezen' geplaatst, omdat het beheren van een account inhoudt dat je deze kunt zien. Als dat breder is dan gewenst, vervang dan 'Alles lezen' door een accountrol die is afgestemd op de specifieke accounts die ze nodig hebben.

Nee. De conversie is eenrichtingsverkeer. Alles wat het produceert is achteraf bewerkbaar, dus elke toegangsregeling die je had kan opnieuw worden opgebouwd met behulp van profielen en rollen.