Support

Hi Nicholas,

Scheduled Akeeba Backup B2 uploads on our Joomla 6 site started failing at post-processing on 2026-05-29. Root cause is on Backblaze's side: they retired API versions 1, 2, and 3 of b2_authorize_account specifically. Only v4 still responds. The Backblaze post-processor in Akeeba Backup 10.3.3 calls v1, so every scheduled run with B2 as the destination now stops at the first authorize call. Small patch attached.

The issue

vendor/akeeba/engine/engine/Postproc/Connector/Backblaze.php (line 49) hardcodes /b2api/v1/ as the authorize entry point, and authorizeAccount() at line 805 calls b2_authorize_account against it. As of 2026-05-29:

Backblaze B2 API Error bad_request:
This request is not currently supported on API version number 1

I verified directly against the B2 endpoint with the same key:

v1	bad_request: This request is not currently supported on API version number 1
v2	bad_request: ... version number 2
v3	bad_request: ... version number 3
v4	200 OK, new nested response shape

The cutoff was narrow: our last successful Akeeba B2 upload finished at 2026-05-28 23:54 UTC; the next scheduled run at 2026-05-29 03:35 UTC hit the rejection. The other Backblaze endpoints used by the connector (b2_get_upload_url, b2_upload_file, b2_list_file_versions, etc.) still respond on v1 today, so the patch only touches the authorize call site and the two response objects.

Every Akeeba Backup install pointed at Backblaze B2 is going to hit this as their scheduled runs fire.

Proposed fix

1. Backblaze.php: change apiURL from /b2api/v1/ to /b2api/v4/. The constant is only used by authorizeAccount(); other endpoints run off the per-account apiUrl returned by authorize, unchanged.
2. AccountInformation.php: in the constructor, detect the v4 nested shape and lift apiInfo.storageApi.* back to the top level before the existing property-assignment loop. v1 still works because the lift only triggers when apiInfo.storageApi is present.
3. Allowed.php: add a $buckets property for the v4 allowed.buckets[] array (which replaces bucketId/bucketName for multi-bucket-scoped keys). Seed bucketId/bucketName from the first entry so single-bucket callers keep working. Update isBucketAllowed() to check the full bucket list when present.

Multi-bucket support in Allowed was necessary in our case because the same runtime key has access to four buckets (GFS rotation). Without it, the seeded bucketName only matches the first bucket and rejects the others.

Full diff attached. 110 lines added, 0 removed. The headline change:

--- Backblaze.php
+++ Backblaze.php
@@ -45,8 +45,19 @@
-	/** The API entry point URL, only used to retrieve the authorization token */
-	public const apiURL = "https://api.backblazeb2.com/b2api/v1/";
+	/**
+	 * The API entry point URL, only used to retrieve the authorization token.
+	 * Backblaze retired v1, v2 and v3 of b2_authorize_account around 2026-05-28/29.
+	 * Only v4 is accepted now. AccountInformation and Allowed unpack both shapes.
+	 */
+	public const apiURL = "https://api.backblazeb2.com/b2api/v4/";

Alternative shapes

• I left the other nine /b2api/v1/ path constants in Backblaze.php alone because they still respond on v1 today. If you'd rather migrate the whole connector in one pass, it is mechanical; I can attach a broader patch.
• The v4 backward-compat path in AccountInformation and Allowed could be removed once it is clear Backblaze is not rolling v1 back. I kept it for safety during the rollover window.

Tested

Patched on our production install, verified end-to-end via Akeeba's composer autoloader against a fresh v4 authorize response and confirmed multi-bucket isBucketAllowed() behaves correctly. Tonight's scheduled GFS daily will exercise the full B2 upload path live.

Thanks for taking a look. Happy to reshape, broaden to migrate the rest of the v1 paths in one go, or drop the backward-compat handling if you'd prefer a cleaner v4-only path.

Brian Mitchell
Intergen

Quick follow-up: this also affects Akeeba Backup for WordPress (verified on 9.1.2).

The three connector files at vendor/akeeba/engine/engine/Postproc/Connector/{Backblaze.php, Backblaze/AccountInformation.php, Backblaze/Allowed.php} are byte-different from the AB-Joomla 10.3.3 copies (different copyright lines, minor formatting) but the actual hunks land cleanly with zero fuzz. The attached patch applies to AB-WP with only the working-directory adjustment (the files live under app/vendor/... instead of administrator/components/com_akeebabackup/vendor/...).

I applied it on a production WP install today after a 22-day silent-failure window: every nightly run reported status=complete but with remote_filename=NULL on the _ak_stats rows (same abort_on_fail shape we discussed in the original report). Three patched files php -l clean. Tonight's scheduled run is the live test on that side too.

Same shared engine, same bug, same fix. Both products affected.

Thanks for the fast turnaround on this, Moira!

One follow-up: 10.3.4 auto-installed on one of our production sites on 2026-06-05, and its CHANGELOG only lists two Quota-page fixes (no B2 entry). The Backblaze connector reverted to the v1 endpoint and our scheduled B2 uploads went silent again until we re-applied the patch this morning. Easy to confirm with grep -c 'b2api/v4' Backblaze.php on a stock 10.3.4 install (currently returns 0).

Do you happen to know which release will carry the fix? We've got a re-apply checklist on the affected sites until then, and knowing the target release would help us scope how long to keep it active. Happy to test against a pre-release build if that's useful on your end.

Thanks again!

Never a worry Nicholas,

I figured something along those lines. If it had somehow slipped through the cracks, I just wanted to be sure it didn't go another release cycle before I pinged it.

Thank you and Moira for the great support as always!

Brian