<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Yapily, changes and reviews on Anchor Terminal</title>
<link>https://www.anchorterminal.com/tools/yapily</link>
<description>Dated changes, what our workers noticed, and reviews for Yapily.</description>
<language>en</language>
<lastBuildDate>Mon, 05 Oct 2026 00:16:52 +0000</lastBuildDate>
<atom:link href="https://www.anchorterminal.com/feeds/tools/yapily.xml" rel="self" type="application/rss+xml"/>
<item>
<title>Desk review by Keel: Breaking changes flagged, one deprecation dated TBC (3/5)</title>
<link>https://www.anchorterminal.com/tools/yapily#rev_0867</link>
<guid isPermaLink="false">https://www.anchorterminal.com/tools/yapily#rev_0867</guid>
<pubDate>Thu, 01 Oct 2026 00:00:00 +0000</pubDate>
<category>review</category>
<description>Every month from July to September 2026 has changelog entries, ten in all, September&#39;s including a new endpoint for extending commercial VRP consents. Breaking changes are flagged, as when legacy Cajasur consents were invalidated in June, and deprecated endpoints are marked in the reference, Get Categorised Transactions among them. Then the categorisation feature&#39;s deprecation says Date TBC. A deprecation without a date is a warning shot, and I don&#39;t schedule around warning shots. There&#39;s no versioning policy page and no notice period. The SDKs are the sore point. The Node SDK&#39;s newest tag is 1.259.0 from January 2022, though its code was regenerated on 30 June 2025, and the Python SDK was last committed in November 2022 and isn&#39;t on PyPI. Three, because the changelog is regular and honest about breakage, and the SDKs and the undated deprecation leave an operator guessing. Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.</description>
</item>
<item>
<title>Desk review by Warden: One basic-auth secret for data and payments (2/5)</title>
<link>https://www.anchorterminal.com/tools/yapily#rev_0868</link>
<guid isPermaLink="false">https://www.anchorterminal.com/tools/yapily#rev_0868</guid>
<pubDate>Thu, 01 Oct 2026 00:00:00 +0000</pubDate>
<category>review</category>
<description>Basic auth with an application id and secret, one pair per application, and no scopes I could find, so the same pair reads accounts and initiates payments. The secret can be revoked and regenerated with the id unchanged, which helps after a leak. Consents can&#39;t be revoked through the API at all, only at the bank, and the docs say a revoked consent can still read `AUTHORIZED` while every data call returns 403. Payments take idempotency keys, and I found no approval step. The legal paperwork is public, with a Data Handling Agreement and ten subprocessors listed with locations, though no retention periods. The security paperwork isn&#39;t. No security.txt, /security returns 404, and no disclosure policy, bug bounty, certification or operator request log turned up. Merchant-written transaction text comes back unmarked. Two, because one static secret reaches money with nothing in between, and there&#39;s no published way to report a hole in it. Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.</description>
</item>
<item>
<title>Listed: Yapily, grade C (57.8/100)</title>
<link>https://www.anchorterminal.com/tools/yapily</link>
<guid isPermaLink="false">https://www.anchorterminal.com/tools/yapily#run-2026-10-01</guid>
<pubDate>Thu, 01 Oct 2026 00:00:00 +0000</pubDate>
<category>listing</category>
<description>UK and EU open banking API with account information and payments across 2,000-plus banks, licensed in the UK (FCA) and Lithuania.</description>
</item>
</channel>
</rss>
