Siirtyminen v3:een

• Osa 1, konsepti. Lue tämä ensin. v3 on uudelleensuunnittelu, ei uudelleennimeäminen: jos yhdistät vanhat päätepisteet yksi yhteen, taistelet APIa vastaan. Kymmenen minuuttia täällä säästää sinulta päiviä myöhemmin.
• Osa 2, API. Päätepiste kerrallaan -kartoitus, esimerkkipyynnöt, tilakoneet ja migraation tarkistuslista.

​

Osa 1, konsepti

​

1.1 Miksi v3 on olemassa

​

1.2 Objektimalli

1. Capabilities ohjaavat kaikkea. Tilit alustetaan ready-tilaisen capabilityn alle; quotet hinnoitellaan capabilitya vasten. Onboarding tarkoittaa tarvittavien capabilityjen saattamista ready-tilaan.
2. Taskit voivat liittyä mihin tahansa. Capability, tili tai käynnissä oleva transfer voi kantaa openTaskIds-arvoa. Missä ikinä näetkin niitä, silmukka on sama: lue task, lähetä vastaukset, odota arviointia, lue vanhempi uudelleen.

​

1.3 Valmius on capability-kohtainen, ei asiakaskohtainen

• “Voiko hän tehdä transaktioita X:llä?” muuttuu muotoon capability X status == "ready".
• “Pitääkö hänen tehdä jotain?” muuttuu muotoon mikä tahansa task tilassa action_required (capability näyttää tyypillisesti restricted ja statusReason.resolution: "complete_tasks").
• “Odotammeko Swipeluxia?” muuttuu muotoon tasks in_review, capability pending.

​

1.4 Task-silmukka

• Task kantaa requirements[]-taulukon, eli yksittäiset pyynnöt. Kullakin on task-kohtainen requirementId, vakaa key, joka nimeää pyynnön (esimerkiksi osoitteentodistus, dedupliko käyttöliittymäsi sillä), ja tyypitetty request, joka kuvaa täsmälleen millaista syötettä halutaan (teksti, päivämäärä, valinta, asiakirja, vakuutus ja niin edelleen).
• Lähettäminen on arviointi-ohjattua: se ei koskaan muuta capabilityn tai tilin tilaa suoraan, hyväksyminen tekee sen. Yksi poikkeus: profile-vastaukset kirjoittavat lähetyshetkellä läpi asiakasprofiiliin (2.3). Lähettämisen jälkeen pollaa taskia tai vanhempiresurssia.
• taskRevision (taskin revision-arvon kaiku) on samanaikaisuuden suoja: jos task on muuttunut sen jälkeen kun luit sen, lue uudelleen ja rakenna vastauksesi uudelleen.
• absence on täysivaltainen vastaus (“Minulla ei ole tätä, koska …”), käytä sitä sen sijaan että jättäisit pyynnöt roikkumaan.

​

1.5 Rahansiirto

​

1.6 Yksi tilakone per resurssi

​

1.7 Käytännöt

• Avaimen uudelleenkäyttö eri rungolla tuottaa 409 idempotency_conflict niin kauan kuin avain säilytetään (vähintään 7 päivää), joten älä koskaan suunnittele uudelleenkäyttöä. Luo tuore UUID per looginen operaatio ja säilytä se työn kanssa.
• Toisto kattaa myös virheet: jos alkuperäinen pyyntö päättyi päättyvään 4xx:ään, sama avain plus runko palauttaa saman virhevastauksen uudelleen.
• Kaksi samanaikaista pyyntöä samalla avaimella: toinen voittaa, toinen saa 409. Yritä häviäjää uudelleen sen jälkeen kun voittaja on ratkennut; toisto palauttaa alkuperäisen vastauksen.

​

1.8 Kultainen polku

​

Osa 2, API

​

2.1 Asiakkaat

// POST /v3/customers        Idempotency-Key: <fresh uuid>
{
  "type": "individual",
  "externalId": "user-1042",
  "individual": {
    "firstName": "Maria",
    "lastName": "Silva",
    "birthDate": "1990-04-12",
    "nationalities": ["BR"],
    "residenceCountry": "BR",
    "email": "maria@example.com",
    "residentialAddress": {
      "streetLine1": "Av. Paulista 1000",
      "city": "Sao Paulo",
      "postalCode": "01310-100",
      "country": "BR"
    }
  },
  "financialProfile": {
    "accountPurposes": ["cross_border_remittance"],
    "sourcesOfFunds": ["salary"]
  }
}

• Luonti on progressiivinen: { "type": "individual" } yksinään on kelvollinen luonti. Puuttuvat tiedot eivät koskaan tee asiakkaasta virheellistä, ne tulevat myöhemmin esiin intake-taskeina niissä capabilityissa, jotka niitä tarvitsevat.
• Yritykset kantavat business-tiedon plus rekisteröintitiedot. v1:n shareholder-CRUD kuvautuu related parties -kokonaisuuteen, joka on laajennettu kattamaan johtajat, toimihenkilöt ja omistajat: luo ne inline asiakkaan luonnissa (kukin saa vakaan rp_-tunnisteen) tai hallinnoi niitä omistetuilla related-parties-päätepisteillä.
• Ei asiakas-status-kenttää, katso 1.3.
• Nykyiset asiakkaat siirtyvät mukana: v1:llä tai v2:lla luodut asiakkaat ovat osoitettavissa samalla tunnisteella v3-päätepisteissä. v3-luku on puhdistettu näkymä, vanhat arvot, jotka eivät läpäise v3-validointia, palautuvat poissaolevina. Ensimmäisen v3-kirjoituksen jälkeen tämä näkymä muuttuu pysyväksi: poissa olevat arvot eivät palaa itsestään. Rikasta siis aikaisin, budjetoi kertaluontoinen ajokerta, joka PATCH-aa täydellisen profiilin omista tietueistasi ennen kuin luotat v3-lukuihin. v1-metadata on erillinen nimiavaruus eikä sitä siirretä, aseta se uudelleen v3:ssa.
• externalId on ensiluokkainen ja yksilöllinen kaikkien asiakkaidesi kesken v3:ssa, ympäristökohtaisesti (409 duplicate_external_id). Asiakkaan arkistointi ei vapauta hänen externalId-arvoaan, tyhjennä se PATCH:lla ennen DELETE:ä, jos aiot käyttää sitä uudelleen.
• DELETE on arkistointikaskadi (ei palautusta; tunnisteita ei koskaan käytetä uudelleen). Se estetään tuottamalla 409 customer_has_active_resources plus blockingResources[] niin kauan kuin arkistoimaton tili tai käynnissä oleva transfer on olemassa.
• PATCH-yhdistämissäännöt: nimenomainen null tyhjentää nullable-kentän, taulukot korvataan kokonaan (paitsi inline related parties, jotka upsertataan tunnisteen mukaan), metadata-avaimet yhdistetään. Täydelliset skeemat ja listasuodattimet ovat OpenAPI-spesifikaatiossa.

​

2.2 /rails, /banks, applications muuttuvat Capabilityiksi

• Capability on method (ach, wire, rtp, pix, sepa, swift, spei, pse, transfers_3_0, faster_payments, sepa_instant, uaefts, card, stablecoin_transfers ja niin edelleen) plus accountType (pooled tai named, null ei-pankkimenetelmille) plus directions (payin tai payout). Julkinen capabilityId on määritelty pari (sepa_pooled, ach_named) tai pelkkä menetelmä card- ja stablecoin_transfers-tapauksissa.
• Jokainen capability-pyyntö synnyttää applicationin, per-yritys-tietueen osoitteessa .../capabilities/{capabilityId}/applications (plus /{applicationId}/history), omilla tiloillaan (1.6) ja statusReason-arvolla. Se on pyynnön kirjausjälki; päivittäin pollaat itse capabilitya.
• capabilities/supported palauttaa saatavuuden (available, beta tai disabled), kelpoisuuden ja tarjolla olevat instituutiot. Pankin valinta tapahtuu pyyntöhetkellä valinnaisen institutions-taulukon kautta, erillistä /banks-resurssia ei ole. Sen jättäminen pois (tai []-arvon lähettäminen) valitsee kaikki oletusinstituutiot; isDefault: true on asiakas- ja capability-kohtainen lippu, ei globaali. Ei-tyhjä lista syrjäyttää oletukset, ja pankkituetulle capabilitylle, jolla ei ole sovellettavaa oletusta, palautetaan 422 capability_institutions_required. Instituutiotunnisteet ovat läpinäkymättömiä, siedä uusia.
• stablecoin_transfers myönnetään automaattisesti asiakkaan luonnissa ja syntyy tilaan ready (sitä ei siis koskaan pyydetä eikä sitä voi peruuttaa). card on vain yksityishenkilöille.
• openTaskIds capabilityssa on “mitä teen seuraavaksi” -osoittimesi. Avoin tarkoittaa action_required tai in_review, ja koonti sisältää jaetut asiakastason taskit, jotka tavoitetaan aktiivisten riippuvuuksien kautta.
• cancel toimii vain tiloista pending tai restricted ja ilman estäviä resursseja, muuten 409 capability_not_cancelable, jonka virherunko listaa blockingResources. Uudelleen pyytäminen peruutuksen jälkeen on tuore luonti uudella idempotency-avaimella.
• Pollaa GET. Capabilityn tila päivittyy, kun luet; pollaa GET .../capabilities/{capabilityId} tai tilaa capability.status_changed, älä cachettaa.
• Yhden menetelmän pyytäminen voi tehdä sukulaismenetelmistä välittömästi saatavilla, käsittele capabilityja joukkona, jonka luet uudelleen, älä yksittäisenä rivinä, jota seuraat.
• Käytä tasks-preview näyttääksesi onboarding-pyynnöt ennen sitoutumista pyyntöön.
• Verifiointi ei ole kertaluontoinen: uusia taskeja voi ilmestyä jo ready-tilaiselle capabilitylle (jaksottainen tai tapahtumavetoinen uusintaverifiointi). Pidä task-silmukka kytkettynä koko asiakkaan elinkaaren ajan, ei vain onboardingissa.

​

2.3 Asiakirjat ja KYC muuttuvat Taskeiksi ja Submissioneiksi

• Raakatiedostojen tallennus: POST/GET/DELETE /v3/customers/{customerId}/documents (plus /{documentId}), lataa kerran API-avaimellasi ja viittaa sitten asiakirjatunnisteisiin submission-vastauksissa. Tämä korvaa jokaisen upload-token- ja direct-upload-vastaanoton.
• Aivan uudet luvut: GET /v3/tasks (kauppiaslaajuinen postilaatikko), GET /v3/transfers/{transferId}/tasks, GET .../tasks/{taskId}/history, GET .../tasks/{taskId}/submissions (plus /{submissionId}).

// POST /v3/customers/{cus}/tasks/{task}/submissions   Idempotency-Key: <fresh uuid>
{
  "taskRevision": 3,
  "answers": [
    { "requirementId": "req_a1", "answer": { "type": "document", "documentIds": ["doc_passport1"] } },
    { "requirementId": "req_b2", "answer": { "type": "text", "value": "Import/export business" } },
    { "requirementId": "req_c3", "answer": { "type": "absence", "reason": "not_applicable" } }
  ]
}

• Vastaustyypit: profile, text, date, single_select, multi_select, boolean, attestation, document, resource_reference, absence. Kunkin requirementin request-objekti kertoo, minkä tyypin se odottaa.
• Submissionin on vastattava jokaiseen toimintaa vaativaan requirementiin nykyisellä kierroksella, tarkalla sinun lukemallasi taskRevision-arvolla. Osittaiset submissionit hylätään.
• profile-vastaukset kirjoittavat läpi: ne päivittävät asiakasprofiilin normaalin validointireitin kautta ja arvioivat välittömästi uudelleen jokaisen samaan intake-työhön viittaavan capabilityn. Sisar-intake-taskit, joiden kaikki requirementit on täytetty, sulkeutuvat automaattisesti.
• Requirementit voivat muodostaa vaihtoehtoisia ryhmiä (alternativeKey): lähetä tasan yksi ryhmästä.
• changes_requested kasvattaa remediationRound-arvoa ja kantaa reviewFeedback-tietoa. Lue task uudelleen ja lähetä uudelleen tuoreella idempotency-avaimella.
• Isännöidyt verifiointi-URLit näkyvät vain asiakaskohtaisessa task-detaljissa (GET /v3/customers/{customerId}/tasks/{taskId}) ja vain niin kauan kuin istunto vaatii toimintaa; listat ja GET /v3/tasks/{taskId} ovat tarkoituksellisesti URL-vapaita.
• Käyttöehdot ovat myös task: openTaskIds voi sisältää taskin category: "terms_of_service", jonka isännöity hyväksymissivu linkitetään samalla tavalla (vain asiakaskohtainen detalji). Yleiset submissionit eivät voi hyväksyä ehtoja, eikä KYC-hyväksyntä koskaan tarkoita ehtojen hyväksyntää.
• Taskit on rajattu capability-kohtaisesti, joten “sama” pyyntö (esimerkiksi osoitteentodistus) voi ilmestyä kerran per capability. Dedupliko käyttöliittymässäsi requirementin key-arvolla.
• Ei käännöskerrosta: /v1/documents-osoitteeseen postaaminen ei avaa v3-capabilityja. Kun asiakas on v3:ssa, ohjaa kaikki pyynnöt taskien kautta.

​

2.4 Tilit ja walletit

// issued bank account (capability must be ready)
{ "origin": "issued", "type": "bank", "method": "sepa",
  "currency": "EUR", "settlement": { "accountId": "acc_wallet1" } }

// external wallet the customer already owns (replaces /import)
{ "origin": "external", "type": "wallet", "currency": "USDC",
  "network": "polygon", "details": { "address": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F" } }

• country myönnetyillä pankkitileillä on valinnainen (oletusarvo per menetelmä); ulkoisilla pankkitileillä anna se nimenomaisesti. Wallet-tilit eivät kanna maata lainkaan.
• settlement.accountId on pakollinen myönnetyillä pankkitileillä: se nimeää myönnetyn wallet-tilin, joka vastaanottaa pankkitilille tehtyjen talletusten selvitetyt varat.
• Myönnetyt tilit paljastavat details-kentän (IBAN tai routing plus tili tai osoite), versioidun routing-kentän (talletuskoordinaatit voivat vaihtua, renderöi aina uusin luku), fees-kentän ja balances-kentän.
• Verkot: polygon, ethereum, base, arbitrum, optimism, bsc, avalanche.
• Capability-portti koskee vain myönnettyjä tilejä: sellaisen luominen ei-valmiin capabilityn alle epäonnistuu capability-koodatulla virheellä, pyydä capability ensin (2.2). Ulkoiset tilit eivät tarvitse capabilitya (eivätkä asiakkaan hyväksyntää); ne saavat vain pyyntöskeeman ja pankkitietojen validoinnin.
• Myönnetyt pankkitilit syntyvät tilaan provisioning, details: null. Pollaa tiliä tai tarkkaile account.status_changed kunnes ready.
• DELETE arkistoi, ei koskaan poista lopullisesti. Tilit, joihin viitataan käynnissä olevista transfereista, palauttavat 409 account_has_active_transfers. Yritä uudelleen sen jälkeen kun nuo transferit ovat saavuttaneet päättyvän tilan.
• Uutta v3:ssa: Rules, pysyvät ohjeet myönnetyllä wallet-tilillä (POST/GET /v3/customers/{customerId}/rules, GET/PATCH/DELETE .../rules/{ruleId}), jotka pyyhkäisevät saapuvat varat automaattisesti toiselle tilille tai wallet-destinationille. Ei v1- tai v2-vastinetta.

​

2.5 Vastaanottajat ja destinationit

• Recipient on kuka: individual (etu- ja sukunimi) tai business (yrityksen nimi), pakollisella relationship-arvolla (employee, contractor, vendor, subsidiary, merchant, customer, landlord, family, other). Recipients ja destinationit ovat vain kolmansille osapuolille. Ensimmäisen osapuolen maksu ei käytä recipientia lainkaan: kohdista quoten destinationId-arvoksi jokin asiakkaan omista acc_-tileistä (2.6).
• Destination on minne: menetelmäkohtaisesti tyypitetty, sepa (iban, bic valinnainen), ach tai wire (routing plus tili), swift (täydet koordinaatit plus valinnainen välittäjä), spei (clabe), pse, transfers_3_0 (cbu) ja niin edelleen, sekä wallet-destinationit. Jokaisella destinationilla on oma tilansa. Tarkkaile destination.status_changed.
• Fiat-destinationit vaativat vastaanottajan täydellisen address-tiedon (katu, kaupunki, postinumero, maa) ennen luontia. Puuttuvat osat epäonnistuvat virheellä 422 recipient_address_required. Wallet-destinationit ohittavat osoitteen mutta vaativat ylätason ownership-arvon (self_custodied tai custodial custodian-nimellä).
• Edunsaajan nimen tarkkuus on tärkeää: vastaanottavat pankit vertailevat tilin laillista nimeä. Lähetä täsmällinen laillinen etu- plus sukunimi tai yrityksen nimi, älä näyttönimeä.
• Menetelmäkohtaiset destinationin kenttäskeemat löytyvät OpenAPI-spesifikaatiosta.

​

2.6 Quotes ja transfers

// 1. Quote: amount on exactly one side picks mode (exact_in / exact_out).
// POST /v3/quotes            Idempotency-Key: <fresh uuid>
{
  "customerId": "cus_123",
  "capabilityId": "sepa_named",
  "in":  { "currency": "EUR", "amount": "150.00" },
  "out": { "currency": "USDC" },
  "destinationId": "acc_wallet1",   // fiat-funded: must be a customer-owned acc_ account
  "fees": { "breakdown": { "developer": { "fixed": "1.00", "bips": 50 } } }
}
// -> { mode: "exact_in", direction: "fiat_to_stablecoin", rate, fees[], expiresAt, ... }

// 2. Execute before expiresAt.
// POST /v3/transfers         Idempotency-Key: <fresh uuid>
{ "quoteId": "quo_789", "externalId": "order-991", "memo": "invoice 44" }

• destinationId ottaa acc_-tunnisteen (asiakkaan omistama tili) tai dst_-tunnisteen (vastaanottajan destination). Fiat-rahoitteisten quotesien (payinien) on kohdistettava acc_-tiliin, dst_-kohde tarkoittaa aina payoutia (muuten 422 quote_direction_invalid).
• externalId quoteissa ja transfereissa on ei-yksilöllinen korrelaatioviite (kaikuu luvuissa, suodatettavissa listoissa). Ympäristökohtainen yksilöllisyyssääntö (2.1) koskee vain asiakkaan externalId-arvoa.
• Suorita quote tasan kerran, ennen expiresAt-arvoa. Vanhentunut quote epäonnistuu virheellä 409 quote_expired, toinen suoritus virheellä 409 quote_already_executed (virhe kantaa olemassa olevan transferId-arvon).
• Transferin peruutusta ei vielä tueta: POST .../cancel palauttaa 409 transfer_not_cancelable jokaisessa tilassa. Nykyiset canceled-transferit tulevat rahoitusikkunan vanhenemisesta rahoittamattomalla payinilla, eivät tästä päätepisteestä.
• Payinit alkavat tilassa awaiting_funds: renderöi GET .../instructions maksajalle, pankkikoordinaatit plus viite- tai memokoodi fiatille, talletusosoite kryptolle. Viitekoodi on tapa, jolla talletus yhdistetään. Näytä se aina.
• state plus stateDetail koneluettaviin alitiloihin; action_required tarkoittaa, että vaatimustenmukaisuustask on liitetty (openTaskIds, GET .../tasks), vastaa submissionien kautta.
• Myönnetyillä tileillä havaitut saapuvat talletukset näkyvät transfereina, joilla on origin: "inbound_deposit" (arvon "quoted" sijaan).
• Maksuverkoston viitteet on koottu references-kohtaan: transactionHash, traceNumber, imad, uetr, explorerUrl, returnedTransferId.

• Transferit eivät ylitä versiorajoja. v1:llä tai v2:lla luodut transferit eivät ole luettavissa v3:sta. Lista jättää ne pois ja GET /v3/transfers/{transferId} palauttaa 404. Siirrä luonti ensin, säilytä v1-lukupolku kunnes nuo transferit saavuttavat päättyvät tilat, ja poista se sitten.
• Ei token-vaihtoja. stablecoin_move vaatii saman valuutan sisään ja ulos: USDC:stä USDT:hen epäonnistuu virheellä 422 recipient_destination_invalid ja currency_mismatch-kenttävirheellä. Sama verkko molemmilla puolilla, ei siltausta, ja wallet-walletiin-siirrot tukevat tällä hetkellä vain maksutonta toimitusta: quote, jonka alusta- tai kehittäjämaksu ei ole nolla, epäonnistuu virheellä 422 amount_not_deliverable.

​

2.7 Webhookit

• GET /v3/webhooks/portal palauttaa isännöidyn hallintaportaalin URLin toimituslokeille, uusintayrityksille ja manuaaliselle toistolle.
• transfer.created toimitetaan tällä hetkellä vanhalla v1-payload-muodolla (v3-kirjekuori aktivoituu, kun v1-webhookit poistetaan käytöstä). Käsittele se puhtaasti vihjeenä ja hae transfer GET:llä; älä rakenna sen rungon varaan.
• Tapahtumat ovat vihjeitä: vastaanotettaessa hae resurssi ja toimi luvun perusteella. Älä koskaan rakenna tilaa tapahtuma-payloadin tai järjestyksen varaan. Toimitus on vähintään-kerran ja voi olla viivästynyt tai uudelleenjärjestetty. Dedupliko tapahtumatunnisteella ja palauta menetetyt tapahtumat kunkin listan sisältävällä updatedAfter-suodattimella.
• Tilaa api.deprecation, versioiden käytöstäpoiston koneellinen kanava.
• Ei task.*-tapahtumaa tällä hetkellä: lähettämisen jälkeen pollaa taskia tai sen vanhempaa.

​

2.8 Sandbox

​

2.9 Vanhat päätepisteet ilman v3-korvaajaa

​

2.10 Ehdotettu migraatiojärjestys

​

2.11 Sudenkuoppien tarkistuslista

• Tuore UUID per looginen operaatio, säilytettynä työn kanssa ja uudelleenkäytettynä uusintayrityksessä; älä koskaan käytä avainta uudelleen muutetulla rungolla (409 idempotency_conflict). Sandbox-päätepisteet on vapautettu otsakkeesta.
• Rikasta olemassa olevat asiakkaat (PATCH täydellinen profiili, aseta metadata uudelleen, se ei siirry) ennen mitään muuta v3-kirjoitusta, ensimmäinen v3-kirjoitus tekee puhdistetusta näkymästä pysyvän.
• externalId on ympäristökohtaisesti yksilöllinen eikä sitä vapauteta arkistoinnissa, tyhjennä se PATCHilla ennen DELETEä, jos aiot käyttää sitä uudelleen.
• Asiakas-status-kenttää ei ole olemassa, johda valmius capability-kohtaisesti.
• action_required ja in_review tarkoittavat molemmat avointa taskia.
• Submissionit ovat arviointiohjattuja (lähettäminen ei ole sama kuin avattu) ja niiden on vastattava jokaiseen toimintaa vaativaan requirementiin tarkalla taskRevision-arvolla. Ristiriidassa lue uudelleen ja rakenna uudelleen.
• task.*-webhookia ei ole olemassa, pollaa taskia (tai sen vanhempaa) jokaisen lähetyksen jälkeen.
• Uusintayritys changes_requested-tapauksessa tarkoittaa taskin lukemista uudelleen, tuoreita vastauksia, tuoretta idempotency-avainta.
• /v1/documents-osoitteeseen postaaminen ei koskaan avaa v3-capabilitya, kun asiakas on taskeissa, ohjaa jokainen pyyntö taskien kautta.
• Uusia taskeja voi ilmestyä jo ready-tilaiselle capabilitylle, pidä task-silmukka kytkettynä onboardingin jälkeen, ei vain sen aikana.
• Capability cancel toimii vain tiloista pending tai restricted ilman estäviä resursseja (409 capability_not_cancelable); uudelleen pyytäminen peruutuksen jälkeen on tuore luonti tuoreella idempotency-avaimella.
• Capabilityn on oltava ready ennen kuin sen alle myönnetään tilejä tai sitä vasten tehdään quoteja.
• Quotessa on määrä tasan yhdellä puolella; ei suuntakenttää; suorita tasan kerran ennen expiresAt-arvoa (409 quote_expired tai 409 quote_already_executed).
• Stablecoin-siirrot ovat vain saman valuutan ja saman verkon (USDC:stä USDT:hen epäonnistuu 422); wallet-walletiin-siirrot tukevat vain maksutonta toimitusta.
• DELETE arkistoi, ei koskaan poista lopullisesti. Tilin poisto estyy käynnissä olevista transfereista (409 account_has_active_transfers); asiakkaan poisto lisäksi mistä tahansa arkistoimattomasta tilistä (409 customer_has_active_resources, blockingResources[] nimeää ne).
• v1- tai v2-transferit ovat näkymättömiä v3-luvuille (lista jättää pois, GET palauttaa 404), kaksoislue kunnes tyhjennetty, poista sitten vanhat polut.
• Talletus-routing ja instructions voivat vaihtua, renderöi aina uusin GET ja näytä aina viitekoodi.
• Webhookit ovat vihjeitä; GET on totuus, dedupliko tapahtumatunnisteella, palauta menetetyt tapahtumat updatedAfter-suodattimella.

​

Seuraava vaihe