Base64 Transcode — strict, both alphabets, per-item errors avatar

Base64 Transcode — strict, both alphabets, per-item errors

Pricing

from $0.20 / 1,000 item transcodeds

Go to Apify Store
Base64 Transcode — strict, both alphabets, per-item errors

Base64 Transcode — strict, both alphabets, per-item errors

Encodes and decodes base64 in either alphabet. Decoding is strict: input that is not well-formed base64 is refused with a reason and a position, instead of being silently repaired into bytes you did not send.

Pricing

from $0.20 / 1,000 item transcodeds

Rating

0.0

(0)

Developer

Alessandro Raffa

Alessandro Raffa

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

3 days ago

Last modified

Categories

Share

Encodes and decodes base64 in either alphabet. Decoding is strict: input that is not well-formed base64 is refused with a reason and a position, instead of being silently repaired into bytes you did not send.

Called as text.base64.transcode.

What it accepts

One direction, one alphabet, and the strings to transcode. Every item gets its own result: a bad item is reported and not billed, and it does not stop the ones after it.

FieldTypeMeaning
directionstringEncode turns text into base64. Decode turns base64 back into text, and refuses anything that is not well-formed.
alphabetstringStandard uses + and / and pads with =. URL-safe uses - and _ and no padding, which is what makes the value usable in a query string or a filename. Decoding refuses the other alphabet's characters, so a mismatch is an error rather than a surprise.
itemsarrayThe strings to transcode, in order. Results carry the index they came from. At most 2,000 per call: at 50 ms an item that is 102 seconds, inside the platform's hard 300-second window for a synchronous call. A larger job is several calls, which is deliberate.

What you pay for

An item that fails is not billed, and one bad item does not stop the ones after it. Every item is charged as it is delivered, one at a time, so a spending limit stops the run at the limit rather than one batch past it.

What would end it

Either the channel absorbs it as a free built-in function, or monthly revenue falls below the cost of keeping it running for two months in a row. Neither is a prediction: both are thresholds checked at every review.

Written before it happens, on purpose. A capability that quietly stops being worth running costs its buyers more than one that says in advance how it ends.


Generated from this capability's own manifest by tools/site/build.mjs. Do not edit it by hand: the next build overwrites it, and pnpm site:check fails while it disagrees with the manifest.