Overgang fra Beta

Dine eksisterende API-nøgler tilbagekaldes ikke og genudstedes ikke. Legitimationsoplysninger, tilladelser og kontotilknytning overføres alle. Eksisterende kald, der ikke sender account_id, fortsætter på Organisationens primære konto. Gennemgå, hvordan din integration vælger en anden konto og håndterer udbetalingssvar.

Vælg en bestemt konto efter behov

Hvis account_id udelades, opererer en privat anmodning på den primære konto:

Vil du operere på en bestemt konto, skal du sende account_id som en query-parameter på URL'en:

Angiv den i URL'en, ikke i request body. En eksplicit account_id tilsidesætter fallback til primærkontoen. Det udvider ikke nøglens kontotilknytning eller tilladelser.

Forstå det nye udbetalingssvar

WithdrawFunds returnerer approval_request_id sammen med refid:

• En refid betyder ikke længere, at udbetalingen er gennemført. Beløbet låses på kildeKontoen, når anmodningen indsendes, og afregnes først efter godkendelse.
• approval_request_id er referencen for den godkendelse, som udbetalingen afventer. Gem den mod din egen registrering.
• Udbetalinger, der afventer godkendelse, vises ikke i WithdrawStatus. En anmodning, der afvises eller udløber, opretter slet ingen udbetalingspost, så fravær fra WithdrawStatus betyder aldrig, at en udbetaling ikke blev indsendt.

Automatisering, der behandler en refid som bevis på gennemførelse, vil rapportere udbetalinger som afregnet, mens de stadig afventer godkendelse. Se API-nøgler for den fulde model.

Din Organisation kommer ud af konverteringen med to sæt standardbyggeblokke.

Workflow Profiles

En Workflow Profile fastlægger, hvad et Medlem kan gøre i hver styret arbejdsgang. Hvert Medlem har præcis én.

Kontoroller

En kontorolle bestemmer, hvad et medlem kan gøre på dine konti. Standardrollerne dækker alle nuværende og fremtidige konti, så et medlem med Trade all kan handle på en konto, du opretter i morgen.

Standardprofiler og -roller følger med produktet: når en ny arbejdsgang tilføjes, får medlemmer med en profil automatisk det rette adgangsniveau. Se Roller, profiler og tilladelser for den fulde beskrivelse.

Hvis et medlems tilladelser ikke matcher nogen standardprofil, tildeles vedkommende en rolle med præcis de tilladelser, de allerede havde. Medlemmer med identiske tilladelser deler én rolle, så din organisation vil have langt færre roller end medlemmer.

Rollerne navngives ud fra den etiket, du havde knyttet til medlemmet, så et medlem med etiketten "Trader" havner i en rolle kaldet trader. Medlemmer uden etiket havner i migrated-role. Hver rolle bærer et migrated-mærke, der viser, at navnet er autogenereret og kan ændres.

Hvorfor dine "Admin"-medlemmer ikke er på Admin-profilen

Beta-etiketten „Admin" gav mulighed for at se, igangsætte og godkende – men ikke for at gennemføre egne anmodninger uden en anden godkendelse. Admin-profilen indeholder netop denne mulighed – det er Execute-niveauet.

I stedet for at tildele det automatisk placeres medlemmer med den gamle etiket i en rolle ved navn beta-admin med præcis de tilladelser, de allerede havde. Du kan til enhver tid flytte dem til Admin med én enkelt tildeling.

Ejeren placeres på Admin-profilen, beholder alle tidligere rettigheder og får automatisk nye arbejdsgange tildelt. Ejeren har også Læs alle, som ikke kan fjernes.

Hvis du bevidst har begrænset ejerens rettigheder, bevares den beslutning: ejeren konverteres til en rolle med præcis de rettigheder, vedkommende faktisk havde, ligesom alle andre medlemmer.

• Alle tilladelser hvert Medlem havde, overføres.
• API-nøglernes legitimationsoplysninger, rettigheder og kontotilknytning bevares.
• Saldi, konti og kontoejerskab er uændrede.
• Godkendelsesanmodninger, der allerede er i gang, fortsætter uændret, ligesom dine politikker, godkendelsesgrænser og indstillingerne for »kræv altid godkendelse«.
• Identitetsbekræftelse påvirkes ikke, og ingen behøver at logge på igen eller inviteres på ny.
• Kun konti, der tilhører din organisation, konverteres. Rettigheder på konti uden for organisationen forbliver uændrede.

Kald uden account_id bruger organisationens primære konto. Hvis du vil rapportere på en anden konto i nøglens kontotilknytning, skal du sende den pågældende kontos account_id i URL'en. Se »Vælg en specifik konto efter behov«.

Kaldet oprettede en anmodning og låste beløbet på kildekontoen. Afregning sker efter godkendelse. Spor anmodningen med det approval_request_id, der returneres af kaldet, eller find den på siden Anmodninger. Se Overførsler og udbetalinger.

Medlemmer, hvis rettigheder ikke matcher en standardprofil, skal hver have en rolle, der bevarer deres adgang, og to medlemmer slås kun sammen i én rolle, hvis deres rettigheder er identiske. Medlemmer, du har givet forskellige etiketter, forbliver på separate roller, selv hvis deres rettigheder stemmer overens, fordi etiketterne antyder, at skellet var tilsigtet. Roller, du ikke har brug for, kan konsolideres ved at tildele deres medlemmer til andre roller og slette den tomme rolle.

Medlemmer, der administrerer organisationen – herunder teamadgang, konti eller API-nøgler – placeres i Læs alle, fordi administration af en konto forudsætter, at man kan se den. Hvis det er bredere end ønsket, kan du erstatte Læs alle med en kontirolle, der er begrænset til de specifikke konti, de har brug for.

Nej. Konverteringen er envejs. Alt, der produceres, kan redigeres bagefter, så enhver adgangsopsætning, du havde, kan genskabes ved hjælp af profiler og roller.