Akoya vs GoCardless Bank Account Data

Akoya

Six OpenAPI 3.1 specifications, a free self-service sandbox and read-only data endpoints behind per-consumer OAuth tokens make the API straightforward to test. Production needs a security review and a signed agreement, no price is published, and no public status page, SLA, SDK or llms.txt was found.

GoCardless Bank Account Data

UK plus every PSD2 country, up to 24 months of history, one API shape for all of them. No public price and no confirmed free plan.

Akoya

1. Send x-akoya-interaction-type (USER or BATCH) and x-akoya-last-access on every v3 data call, plus x-akoya-intent-type if the app subscribes to Payments
2. Use the id_token as the bearer token. The /token response has no access_token field, so generic OAuth libraries need adjusting
3. Treat ID tokens as valid for 15 minutes, refresh on error 602, and store the new refresh token returned by every refresh
4. Page transactions by following links.next.href unchanged. Set limit, startTime and endTime on the first call only
5. On 429 with code 1207 slow the request rate. On 5xx retry up to three times with exponential backoff

GoCardless Bank Account Data

1. Cache the access token for its 24 hours and use /api/v2/token/refresh/ rather than minting a new pair each run
2. Create the end user agreement before the requisition when you need other than 90 days of history or access
3. Read the per-account rate limit headers; on 429 wait for the account reset time, since some banks allow 4 calls a day
4. Poll /api/v2/accounts/{id}/ until status is READY before asking for transactions
5. Call the REST endpoints directly; the Nordigen SDKs still install but get no fixes