DEV Community: Bowhard

Publishing community templates to the n8n library: what the review actually asks for

Bowhard — Sat, 10 Oct 2026 22:47:55 +0000

The n8n template library is one of the few places where a self-hosted automation builder can publish something for free and get real traffic from it. It is also a gatekept library: every submission is reviewed by a human, and the guidelines are stricter than the form suggests. We have submitted templates from a self-hosted instance, and this is the checklist we work from — what the review actually looks at, in the order it tends to matter.

The submission itself happens at creators.n8n.io, not in the n8n app. You register a creator account, verify the e-mail, and submit from the dashboard. Everything below is drawn from the official template submission guidelines and the separate sticky-note guidelines; if a rule here contradicts what you read there, trust them, not this post.

The one-template rule that surprises everyone

A new author (an account that has not been verified yet) may have exactly one template under review at a time. The button for the next submission stays disabled until the previous one is approved or sent back. There is no queue, no batching, and no way to speed it up from your side.

That single rule changes how you plan a set of templates. If you have three workflows ready, do not polish all three in parallel and hope to ship them in a week: you ship one, wait for review, then start the next. It also means the first submission is disproportionately expensive — a rejection costs you a full review cycle, so it is worth spending the extra hour on the sticky notes.

After three approved templates the account becomes verified. Verified authors get a badge, batches of up to four submissions instead of one, access to the closed n8n Discord, and the right to publish paid templates. Getting to three is the actual goal; the individual templates are the mechanism.

Titles: "action verb + object + where or from"

The title formula is not a style preference, it is a review criterion. Send website form leads to Google Sheets and Telegram is accepted shape: verb (Send), object (website form leads), destinations (to Google Sheets and Telegram). Ultimate AI Automation Beast 🚀 is not, for three separate reasons.

Practical consequences:

No emoji and no hype words. "Powerful", "ultimate", "revolutionary", "10x" all read as marketing rather than description.
Name the services concretely. "Your CRM" is vague; if the workflow talks to HubSpot, say HubSpot. Reviewers are checking that the title describes what the JSON actually does.
Keep it under the limit and check the rendered length. The library truncates on cards, and a truncated title loses the "where" half of the formula.

Our own three titles, for reference:

Send website form leads to Google Sheets and Telegram
Send a daily sales report from your CRM to Telegram
Answer customer questions from your knowledge base with an AI model

The description is a 200-word structured document

The description is English markdown, roughly 200 words, and it is expected to have sections, not a paragraph. The shape that reviewers look for:

Who it is for — the reader's job, not the workflow's features.
How it works — the steps in order, in prose.
How to set up — what to click, in what order, after import.
What you need — the services, credentials and plan requirements.
How to extend — an honest pointer at the part that is designed to be edited.

No HTML. Emoji are tolerated in the body far better than in the title, but the markdown has to render cleanly in the library's own renderer, which is stricter than a GitHub README — nested tables and raw HTML tend to come out mangled.

Sticky notes are mandatory, and one of them is not a note

This is the requirement people skip, and it is the one that gets a template sent back. Sticky notes in the workflow are not optional decoration: they are how the reviewer (and the person who imports your workflow six months from now) understands it without opening a single node.

The rule has two halves:

One yellow note carries the whole description. Not a summary — the full text that also goes into the submission form. The yellow note is the canonical copy.
Every other note is a neutral, step-level annotation — "Validate the e-mail before writing to the sheet", "Retry once on 429". They describe the step, not the template.

If you keep the description in two places, they will diverge within a week. In our repository the submission description is generated by a build script that reads the description straight out of the workflow's own yellow sticky note, so the form and the JSON cannot disagree. If you write your own tooling, do it in that direction: JSON is the source, the form is the copy.

Node names are read as documentation

The default n8n names (Set, HTTP Request, IF) tell a reader nothing. Renaming is expected, and it is checked: a workflow where the AI branch is labelled Normalize lead fields and Score against ICP rules is reviewable in a screenshot; one with four Set nodes in a row is not.

The same logic applies to sticky notes that arrange the canvas into sections — they should name the stage of the pipeline, not repeat the node names.

Nothing secret, nothing personal, nothing live

The exported JSON is public the moment it is approved, so review looks for anything that leaks or breaks someone else's instance:

No API keys or tokens anywhere in the workflow, including inside HTTP Request node headers, query parameters and JSON bodies. This includes disabled nodes — reviewers open those too.
No personal or tenant identifiers: real spreadsheet IDs, channel IDs, chat IDs, calendar IDs, e-mail addresses, internal hostnames. A real spreadsheet ID in a template is both a privacy problem and a broken template for everyone else.
Webhook paths should no longer be live. Rename them if the original path was reachable.
Credentials should not be embedded. Our exported workflows deliberately contain no credential blocks at all — the import dialog then asks the user to attach their own credential to a named node, which is the behaviour you want.
Replace placeholders with obvious placeholders. We use REPLACE_WITH_YOUR_CHAT_ID, REPLACE_WITH_YOUR_TOKEN, YOUR-N8N-HOST and example.com — strings that are unmistakably not real values, and greppable in the documentation.

A template whose HTTP node contains only a token placeholder and a documented "attach the credential here" step is also one your own account survives: the JSON in a public repo should not be the JSON that runs your production.

Preparing the JSON

The template artefact is a single exported workflow file, and preparing it is a mechanical pass:

Build the workflow in a clean project. Not in the instance where it already runs with live credentials.
Rename every node, describe every stage, add the sticky notes.
Strip credentials and replace every environment-specific value with a placeholder.
Check that it imports into a fresh instance: Workflows → ⋯ → Import from File. If a node shows a red error badge before you have attached anything, the template will be sent back.
Test the happy path with a real credential, and keep the curl invocation that exercises it in the template README.
Export, then re-import the exported file and read it once more. This catches the placeholder you replaced in the wrong branch.
If you used a community node, the submission needs a top image — a screenshot of the workflow canvas with the sticky-note sections visible works best. Workflows that use only built-in nodes (ours do) do not need one.

Publishing the same JSON in a public repo alongside the submission gives reviewers and users the same source of truth, and gives you a licence statement to point at — ours is MIT.

What reviewers are actually filtering for

Two prohibitions are worth stating explicitly because they are instant rejections rather than fixable notes: plagiarism (a renamed copy of an existing library template) and low-effort templates (one node wrapping one API call, or a workflow that only works after the user rewrites half of it).

The practical test we apply before submitting: would this still be useful to someone who does not use our service, and does every node in it earn its place? Our own submissions are business reporting and lead-intake workflows built on that standard, and the ones that touch our transcription HTTP API are documented so that the API call is one clearly-labelled step rather than the whole template.

The template collection, JSON and per-template READMEs: https://github.com/VavilkinAlex/n8n-bowhard-templates
Official submission guidelines: https://n8n.notion.site/p/Template-submission-guidelines-9959894476734da3b402c90b124b1f77
Sticky-note guidelines: https://n8n.notion.site/Sticky-note-guidelines-for-templates-2aa5b6e0c94f8058b0aefddd02655887

Building a zero-dependency Python and Node client for a speech-to-text API

Bowhard — Sat, 10 Oct 2026 22:46:00 +0000

Most speech-to-text and text-to-speech APIs ship a fat SDK: a package manager, a dependency tree, a version matrix. We went the other way. Our transcription and synthesis service speaks plain HTTP with JSON payloads and exactly one multipart upload, and we wrote the reference clients as a proof: they talk to the API with nothing but the standard library. No requests, no axios, no node-fetch — Python's urllib and Node's built-in fetch.

This is a walkthrough of how those clients work and which parts of the API forced the design. The code is on GitHub at VavilkinAlex/bowhard-speech; the endpoint reference is at bowhard.ru/api.

No API key means the cookie jar is the client

The service does not issue API keys. It sets a signed cookie (tools_id) on your first request and counts your daily free volume — 15 minutes of transcription and 5,000 characters of synthesis — by that cookie. Your jobs are bound to the same identity.

That single decision shapes both clients: the client is a cookie jar plus a request wrapper.

In Python that is one line of standard library:

import urllib.request
from http.cookiejar import CookieJar

self._opener = urllib.request.build_opener(
    urllib.request.HTTPCookieProcessor(CookieJar())
)

Every call goes through self._opener, so Set-Cookie on the first response is replayed on all the following ones without any code from us.

Node is where it gets interesting. fetch is built in and good enough, but it is deliberately stateless about cookies — there is no jar. So the Node client carries its own, a plain Map:

this.cookies = new Map();

// when sending
if (this.cookies.size) {
  headers.cookie = [...this.cookies]
    .map(([k, v]) => `${k}=${v}`)
    .join('; ');
}

// when receiving
for (const raw of response.headers.getSetCookie?.() || []) {
  const [pair] = raw.split(';');
  const [name, ...rest] = pair.split('=');
  this.cookies.set(name.trim(), rest.join('='));
}

Two details are easy to get wrong. First, getSetCookie() — the plural accessor — is what you need; the single headers.get('set-cookie') flattens multiple cookies into one string and breaks parsing. Second, you must keep only the name=value part: the attributes after the first semicolon (Path, HttpOnly, Max-Age) are server-side instructions, not something you echo back.

One consequence worth stating plainly: one client instance is one job owner. Creating a new Client discards the cookie, and with it the ability to read the jobs it just started. If you build a worker that fans out work, keep one instance alive.

Building multipart by hand in Python

There is exactly one place where a JSON library is not enough: POST /api/tools/stt wants multipart/form-data with a file field. urllib has no multipart encoder, so the Python client assembles the body itself:

boundary = uuid.uuid4().hex
parts = []

for key, value in (extra or {}).items():
    parts.append(
        f'--{boundary}\r\n'
        f'Content-Disposition: form-data; name="{key}"\r\n\r\n'
        f'{value}\r\n'.encode('utf-8')
    )

mime = mimetypes.guess_type(filename)[0] or 'application/octet-stream'
parts.append(
    f'--{boundary}\r\n'
    f'Content-Disposition: form-data; name="{field_name}"; '
    f'filename="{os.path.basename(filename)}"\r\n'
    f'Content-Type: {mime}\r\n\r\n'.encode('utf-8')
)
parts.append(content)
parts.append(f'\r\n--{boundary}--\r\n'.encode('utf-8'))

body = b''.join(parts)
content_type = f'multipart/form-data; boundary={boundary}'

The rules that actually matter:

The boundary must not appear in the payload. A random 32-character hex string from uuid4() makes that a non-issue.
CRLF, not LF. The spec says \r\n and some parsers check. Python's email module would handle this, but then you are back to assembling anyway.
Extra fields come before the file part. Cheap to respect, annoying to debug when a proxy-side parser assumes order.
Send the basename, not the path. filename="/home/you/secret/meeting.mp3" leaks your directory layout to the server and to any log in between.
Always send a Content-Type per part. mimetypes.guess_type() covers the formats the service accepts (mp3, wav, ogg/opus, m4a, mp4, mov, mkv — anything ffmpeg reads); application/octet-stream is the fallback.

The same request in Node is four lines, because Node 18+ ships FormData, Blob and fetch together:

const form = new FormData();
form.append('file', new Blob([await readFile(filePath)]), basename(filePath));
const response = await this.#request('/stt', { method: 'POST', body: form });

fetch writes the boundary and the part headers itself. The interesting part is that the server cannot tell the two apart — a hand-rolled body and a FormData body are the same bytes on the wire.

Timeouts and retries

The two clients make opposite choices here, on purpose.

Python uses a single attempt with a 120-second timeout: urllib raises, the client translates the exception into its own error type, and the caller decides. Retrying a request that uploads a 200 MB recording automatically is not obviously a kindness.

Node retries — up to three attempts, with a linear backoff of 500 * (attempt + 1) milliseconds — because the failure it most often hits is a dropped connection on a long upload, and fetch gives it a clean AbortController to bound each attempt:

const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), this.timeout);

The timeout is per attempt, not per operation, which is the behaviour you want: three tries of 120 seconds each, not one budget of 120 seconds split three ways.

Polling, because transcription is not instant

Uploading a file does not return text. It returns a job:

{"id": "abc123", "kind": "stt", "status": "queued"}

Transcription happens in a queue — the service processes two files at a time and the rest wait — so the time to completion depends on what else is running and on the length of your recording. There is no honest way to predict it, which is why the API is poll-based rather than webhook-based: a webhook would need a publicly reachable URL from you, and most client code does not have one.

GET /api/tools/job/{id} returns everything you need to decide what to do next:

field	meaning
`status`	`queued`, `processing`, `done`, `error`
`stage`	what the worker is doing right now (used for progress output)
`error`	human-readable failure reason when `status` is `error`
`durationSec`	length of the audio
`chars`	number of characters for synthesis jobs
`costRub`, `free`	what this job cost and whether it came out of the free daily allowance
`files`	the result files that are ready to download

Both clients wrap that in a wait() helper that polls every 3 seconds, prints progress through a callback, and gives up after an hour by default:

job = client.transcribe("meeting.mp3")
job = client.wait(job.id, on_progress=lambda j: print(j.status, j.stage))

const job = await client.transcribe('meeting.mp3');
await client.wait(job.id, { onProgress: (j) => console.log(j.status, j.stage) });

Three seconds is a deliberate compromise. A tighter loop gains nothing — the queue position changes on the scale of seconds — and every poll is a request against the same cookie-counted account.

Downloading the results

GET /api/tools/job/{id}/file/{kind} serves the artefacts, where kind is one of four:

txt — the plain transcript, one paragraph flow, no timecodes;
srt — subtitles, already wrapped to a maximum of 42 characters per line, which is the usual readability norm and the same limit our subtitle converter uses;
json — the same transcript with a timecode for every single word, which is what you need if you are cutting video against the speech rather than just captioning it;
mp3 — the synthesised audio, for text-to-speech jobs.

In Python the helpers return strings or bytes (client.text(job.id), client.srt(job.id), client.words(job.id), client.audio(job.id)); in Node they return strings or a Buffer. Both have a save() that writes straight to a path. One operational note: results live for 24 hours, and the job statistics are kept for 90 days. If a transcript matters, download it in the same run that produced it.

Errors that carry the server's own message

An HTTP client that hides the response body costs you an hour of guessing. Both clients parse the error payload before throwing, and fall back to a truncated raw body when the response is not JSON:

try:
    ...
except urllib.error.HTTPError as error:
    body = error.read()
    try:
        payload = json.loads(body.decode('utf-8'))
    except ValueError:
        payload = {"error": body.decode('utf-8', 'replace')[:300]}
    raise BowhardError(payload.get('error') or f'HTTP {error.code}',
                       error.code, payload)

The resulting BowhardError carries status and payload, so except BowhardError as e: print(e.status, e.payload) tells you whether you hit a rate limit (more than ten link imports per hour), a bad file type, or an expired job — without parsing strings.

The whole thing

Both clients are a couple of hundred lines each, under MIT, with no dependencies to install and no lockfile to audit. Installation for the Python one is a single wheel from the repository's releases; the Node one installs from GitHub Packages. If you would rather not write HTTP by hand at all, there are CLI entry points in both:

bowhard-speech transcribe soveschanie.mp3 -o protokol.txt --srt protokol.srt
bowhard-speech say "…" -o privet.mp3 --voice alena --speed 1.1
npx bowhard-speech transcribe meeting.mp3 --srt meeting.srt

The interesting lesson is not "write your own HTTP client". It is that the API was small enough to make that a reasonable afternoon's work: one cookie, one multipart endpoint, one job resource, four file kinds. If your client library needs a dependency tree, it is usually because the API asked for one.

Client libraries (Python + Node, MIT): https://github.com/VavilkinAlex/bowhard-speech
HTTP API reference: https://bowhard.ru/api
The transcription service itself: https://bowhard.ru/rasshifrovka

Speech-to-text and text-to-speech on Yandex SpeechKit from one Python stdlib file

Bowhard — Sat, 10 Oct 2026 22:06:28 +0000

The problem was mundane. On one side, meeting recordings: an mp3 of an hour or an hour and a half, out of which I needed text and subtitles. On the other, the reverse operation: I have text, I need a voice, because some clients listen rather than read. I did not want to buy a separate SaaS for this — the recordings are internal, and paying a subscription for them costs more than paying for the actual minutes.

The constraints I set for myself up front:

one VPS, no external queues or brokers;
no dependencies beyond the system ffmpeg/ffprobe — so that an update means replacing one file and restarting a systemd unit;
recognition and synthesis go straight to Yandex SpeechKit v3, with no middleware;
user files are not kept longer than a day;
cost has to be predictable: the service must not run at a loss because someone else's script uploads hour-long recordings all night.

What came out is a single Python 3.12 file of roughly 2,200 lines: http.server with threads, sqlite3 as the job queue, urllib for everything external, ffmpeg for conversion. Below is what turned out to be non-obvious in this construction. Not a tutorial — a field notes collection of the places it bites.

Why the standard library was enough

The stock ThreadingHTTPServer cannot cap the number of concurrent connections: on a slow client it happily spawns thread after thread until file descriptors run out. I needed my own subclass — with a pool of 32 connection slots and a 120-second request read timeout. Everything else is ordinary routing: file upload via multipart, a JSON API for job status, result delivery, and the payment provider's webhook.

The queue is hand-rolled too, and it is surprisingly boring: a jobs table in SQLite, two worker threads, the statuses queued → processing → done|error, and a stage field holding a human-readable string like "converting" or "recognizing". Here sqlite3 works as an ordinary job log rather than a high-load database: one row written per job, one row read per status poll.

What that bought in practice: deploying the service is scp of one file plus systemctl restart. No pip install, no migrations, no "your library version is wrong".

The public REST API is documented at bowhard.ru/api, and since I am not the only one who wanted to drive this from a script, there are small clients for Python and Node — that is how the transcription and text-to-speech services at bowhard.ru/rasshifrovka and bowhard.ru/ozvuchka are consumed from automation.

Recognition: asynchronous, because the file is long

SpeechKit can do synchronous recognition, but that is for short utterances. An hour-long recording means recognizeFileAsync: send a job, get an operationId, poll the status until it is done. Poll every two seconds, with a three-hour deadline. Going below two seconds is pointless — the operation cannot have finished anyway, and you are just hammering the API for nothing.

The input to SpeechKit comes in two flavours, and the choice between them is not cosmetic:

content — audio as base64 inside the request body. Fine for small files, but base64 inflates the size by about a third, and holding an encoded hour-long recording in memory is not a great idea;
uri — a link to an object in S3-compatible storage. We adopted a rule: files from 8 MB up go to Object Storage, anything smaller goes as base64. The threshold was picked from process memory: 8 MB in base64 is roughly an 11 MB string, which is perfectly safe for two workers.

The result of getRecognition is not JSON but a stream of JSON lines, one object per line — that is the first non-obvious thing. It contains both the plain recognized words and a finalRefinement.normalizedText.alternatives block. The words are needed for timings, but they carry no punctuation and no capital letters. The finished text with punctuation lives in the text field of that same normalizedText block. So we take the text from there, the timings from the word array, and splice the two into a single result.

Subtitles are assembled from that same result. SRT is a format that forgives a lot except two things: over-long lines and overlapping timecodes. We break the line by words, never letting it exceed 42 characters, and wrap only at a word boundary. A subtitle block looks like this:

the block number line — 12;
the time line — 00:01:04,320 --> 00:01:07,880, with milliseconds separated by a comma, as the format requires;
one or two lines of text, split by words and no longer than 42 characters each — and we decided not to touch that part.

The timecodes come straight from the words, so the subtitles end up denser than when you slice by sentences, and they do not drift on fast speech. The user gets three files: the text, the .srt, and a json with the words and their timings — the last one is for anyone who wants word highlighting in a player.

Text-to-speech: 240 characters that nearly broke everything

Synthesis in v3 is called through the utteranceSynthesis method, and it has a limit on text length that the documentation says approximately nothing about. It emerged empirically: 250 characters pass, 500 come back as a refusal reading "Too long text". And the refusal does not always arrive straight away: sometimes it looks like a dropped connection, and had I not been logging the response body, I would have hunted for the cause for a long time.

The fix is to cut the text into chunks of 240 characters, and to do it on sentence boundaries rather than by a character counter. It is inaudible, and the price is computed from the source character count, so the splitting does not affect the cost at all.

Then comes the pleasant part: MP3 is a sequence of independent frames, so the synthesized chunks are joined by plain byte concatenation, with no re-encoding and no ffmpeg. But if you cut the text crudely, mid-sentence, you can hear an unnatural pause at the seam — which is why the splitting happens at periods, question marks and exclamation marks.

Two more things about synthesis. First: the v1 API costs roughly twice as much as v3 for the same result, so you should go straight to v3. Second: the speed parameter is accepted in the range 0.5–2.0, and anything outside it has to be clamped on your side, otherwise you get an error in the middle of a long text. SpeechKit has fifteen voices — from the neutral "Alena" to the conversational "Zakhar" — and for internal recordings the difference between them is far more noticeable than for advertising ones.

The queue, the ceilings, and the money fuse

The nastiest class of bug in a service like this is not a crash but quietly burning money. So the ceilings are set at every level:

no more than three jobs in flight per visitor;
no more than 600 MB of uploads per day from one address;
no more than 10 link imports per hour;
the job directory cannot exceed 6 GB — past that, new jobs are refused until cleanup runs;
and the main fuse: a daily cost ceiling. If the total recognition cost for the day exceeds a configured threshold, the service stops accepting new jobs and says so plainly, instead of running at a loss until morning.

A separate trap in the same area is balance accounting. Transcription is measured in minutes of audio, text-to-speech in characters. It is natural to keep both in one credits table, but if you compute usage as one combined sum you get nonsense: minutes get eaten by synthesis, characters by transcription, and the balance goes negative out of nowhere. Usage has to be counted separately per kind of work, and the interface has to show two independent balances. In the code this story survives as a comment — as a reminder.

Link import: SSRF is not only about the URL

A "paste a link to a file" feature saves the user time and creates a whole class of risk. Ours is narrowed to two providers: public Yandex Disk files (via cloud-api.yandex.net) and Dropbox. The list of trusted hosts is an allowlist, not a denylist, and the check is repeated after redirects: a provider may send you to another domain, and that is fine, but only if that domain is on the list too.

Timeouts are split as well: 30 seconds for the provider's response and 600 seconds for the download itself, otherwise the service turns into a free relay for other people's slow files. Plus a per-address attempt counter. A dedicated self-test command exercises these scenarios: selftest_links, selftest_sign, selftest_net — three buttons that ask "check that the outside world is still what we think it is".

Payments: we do not trust the webhook

Payment goes through YooKassa, and there is exactly one rule here that must not be broken: a webhook is not confirmation of a payment. It is only a reason to re-check. The scheme is this: the payment is created in the database up front with a "created" status; on notification the service makes a separate GET /payments/{id} request to the payment provider's API, looks at the real status, and only then credits the balance.

The crediting itself must happen exactly once, because webhooks repeat. Instead of "read the flag, write the credit", a conditional update is used: UPDATE payments SET paid_at = ? WHERE id = ? AND paid_at IS NULL, and the credit is granted only if that statement actually changed a row. This is cheaper and more reliable than any lock in the application: the race between two simultaneous webhooks is settled by the database.

Storage: signing SigV4 by hand

Files from 8 MB up go to S3-compatible Object Storage. I did not want to pull in an SDK for four operations (PUT, GET, DELETE, HEAD), so the AWS SigV4 signature is assembled by hand on urllib — and that turned out to be the most capricious part of the whole project.

Two traps, both diagnosed equally unpleasantly — just a 403 with no explanation:

x-amz-content-sha256 has to appear both in the canonical headers and in the SignedHeaders list. The header is sent, the hash is computed, and the signature still does not match, because it is missing from the list being signed.
Sub-resources such as ?lifecycle are written in the canonical request as lifecycle= — with an empty value. Leave them as they are and you get SignatureDoesNotMatch on a request that looks externally flawless.

Once the signature is assembled, though, everything else is trivial: put the object — hand SpeechKit the link — delete the object after cleanup. Job files live for 24 hours: that promise is written on the service page, which means the background cleanup has to honour it literally rather than "eventually". Statistics records are kept for 90 days — enough to understand load and compute cost.

What I would do differently

The SpeechKit client should have been extracted into a separate module from week one: right now the recognition, synthesis and queue logic all live in one file, and that is convenient exactly until the moment you want to run synthesis from a separate script. Second — progress for long operations: today it shows the stage and a speed estimate based on already-processed jobs, but an honest completion fraction for an hour-long recording would be more useful. Third — move the free-tier limits into config rather than code: those are the ones you want to change more often than anything else.

Otherwise the construction "one file, stdlib, SQLite and system ffmpeg" has held up better than I expected: the service handles recordings up to four hours, recognizing an hour-long file takes less time than the recording itself lasts, and updating it requires neither a build nor dependencies.

If you want to drive this from an automation platform rather than from code, there are ready-made n8n workflow templates for both transcription and synthesis. And if you build something similar, the most expensive time will go not into SpeechKit but into the S3 signature and the balance accounting — start with those.