Akoya vs Salt Edge Account Information

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.

Salt Edge Account Information

5,000-plus banks in more than 50 countries, by Salt Edge's own count. Rate limit exceeded returns HTTP 406 RateLimitExceeded, not 429.

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

Salt Edge Account Information

1. Treat HTTP 406 with error_class RateLimitExceeded as a rate limit and back off; it isn't a content-negotiation error
2. Start with fakebank_simple_xf in country XF; it needs no bank sandbox
3. Sign requests from the start even in Test, so the move to Live doesn't change your client
4. Follow next_page from the meta block rather than building from_id URLs yourself
5. Revoke with PUT /api/v6/consents/{consent_id}/revoke when the user is done