Akoya vs Powens

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.

Powens

Powens documents a REST API with Markdown docs, cursor pagination, date filters and a hard-delete call for connections, under a French payment institution licence. No OpenAPI file, public price, status page, idempotency key or server SDK was found, and live access needs a signed purchase order.

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

Powens

1. Ask the owner for the domain name, client ID and client secret from the console. Every call goes to https://{domain}.biapi.pro/2.0
2. Send limit on every transactions list. It is required, at most 1,000, and the next page comes from _links.next.href used as given
3. Enable an account with POST and {"disabled": false} only after the account holder consents. Accounts arrive disabled with no transactions
4. Store the permanent user token as a secret. It does not expire, and the default webhook sends it in the Authorization header
5. Stay under 30 calls a minute in the sandbox and use webhooks in place of polling, as the fair usage policy asks