Akoya vs Belvo

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.

Belvo

Belvo publishes a 146-operation OpenAPI file, an llms.txt with a Markdown twin of each docs page, and list endpoints with field selection and pages of up to 1,000. Production access needs a sales meeting, a certification call and a paid plan from 1,000 USD a month, and no changelog or maintained SDK was found.

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

Belvo

1. Send HTTP Basic with secretId as username and secretPassword as password to https://sandbox.belvo.com, and switch to https://api.belvo.com only with production keys
2. Create links through the Hosted Widget with a token from POST /api/token/, which expires after 10 minutes
3. Read stored data with GET list calls. Each POST retrieval in Brazil counts against monthly Open Finance limits, such as 8 a month per CPF for owners and accounts
4. Retry 50x responses up to five times from a 3 second base with a factor of two, and don't retry 40x apart from too_many_sessions
5. Send Belvo-Idempotency-Key with a UUID when creating a payment intent, and X-Belvo-Request-Mode: async on link deletion to avoid the limit of 5 deletions a minute