Wynko for Laposta

Laposta explains it here: https://docs.laposta.org/article/947-how-do-i-get-an-api-key Paste the key into Wynko → Settings. Wynko makes a live check with Laposta before saving, so an invalid key is caught straight away.

Put it in your wp-config.php file rather than in the settings screen: define( 'WYNKO_API_KEY', 'your-laposta-api-key' ); Why this is better: your database gets backed up, exported, copied to staging sites, and is the first thing an attacker goes looking for. A key in wp-config.php isn't in any of that. It also means the key travels with your deployment rather than being re-entered by hand on every environment. Two things to know:

• A key defined this way always takes priority, and Wynko won't save a database value that would shadow it.
• Because it isn't in the database, uninstalling Wynko won't remove it. Delete the line from wp-config.php yourself when you're done.

When your server allows it: if the sodium PHP extension is available (bundled with PHP since 7.2, so almost every host has it) and your site has real SECURE_AUTH_KEY/SECURE_AUTH_SALT values in wp-config.php — the ones WordPress itself generates, and the same ones you'd rotate as part of an incident response — Wynko seals the key with authenticated encryption (libsodium's secretbox) before writing it to the database. A raw database export, a SQL-injection leak, or an administrator browsing the options table doesn't hand over a usable key. What this protects against: exposure of the database on its own — a leaked backup, a stray export, a SQL-injection read. What it doesn't protect against: anyone who can also read wp-config.php. Your security salts live there, right alongside your database credentials, so someone with filesystem access already has everything needed to open the key. For that level of protection, keep the key out of the database entirely with the WYNKO_API_KEY constant or environment variable described above. If you rotate SECURE_AUTH_KEY — standard practice after a suspected leak — every previously sealed key becomes unreadable on purpose. Wynko treats that exactly like no key being configured (it will never send garbage to Laposta), and the settings screen tells you plainly what happened so you can re-enter it. If your server has no sodium extension, or your site is still running WordPress's placeholder salts, the key is stored as plain text and the settings screen says so.

Yes. Every setting below can come from an environment variable (your .env file, web server config, or container definition) or a wp-config.php constant. An environment variable always outranks a constant, and a constant always outranks whatever is saved on the settings screen. On multisite, suffix the blog ID to override one site only — for example WYNKO_API_KEY_3 or WYNKO_THROTTLE_WINDOW_3 — otherwise the value applies network-wide.

• WYNKO_API_KEY — the Laposta API key (see above).
• WYNKO_CACHE_MINUTES — how long campaign data is cached before Laposta is asked again. Default: 60.
• WYNKO_LOG_LEVEL — the lowest severity recorded in the activity log: error, warning, or info. Default: info.
• WYNKO_THROTTLE_WINDOW — the signup rate-limit window, in minutes. Default: 10.
• WYNKO_THROTTLE_IP_MAX — signups one visitor may submit per window, across all your forms. Default: 15.
• WYNKO_THROTTLE_FORM_MAX — signups one form may take per window, from every visitor combined. Default: 400.
• WYNKO_NOTIFY_ENABLED — whether critical-error email alerts are on. Default: off.
• WYNKO_NOTIFY_EMAILS — comma-separated addresses that receive those alerts.

A few layers, all before anything reaches Laposta:

• A hidden honeypot field — a bot that fills it in is shown the normal success message, but nothing is actually sent to Laposta.
• Rate limiting per visitor and per form, over a rolling window (see the next question for the defaults and how to tune them).
• Full server-side validation against the list's real fields in Laposta, regardless of what a script sends — required fields, allowed choices, value ranges, text length and patterns.
• A security token scoped to each individual form, checked before anything else in the submission is read.
• Identical responses to a forged token, an unknown form, and a rate-limited request, so a script probing the endpoint can't learn which check it failed.
• "Already subscribed" answered the same as a new signup by default, so the form can't be used to check whether a given address is on your list.

By default, one visitor can submit up to 15 signups, and one form can accept up to 400 signups in total, within any rolling 10-minute window. All three numbers live on the Security tab and can be changed — the per-visitor and per-form caps go up to 1000 and 100,000 respectively, and the window up to 24 hours. Raise the per-visitor cap if a shared office, school, or NAT gateway sends real visitors from a single address — that's the most common reason a legitimate visitor gets turned away. Treat the per-form cap as a backstop rather than a first line of defense: keep it well above your form's real traffic, because a form that reaches it turns away every visitor, real or not, until the window passes. If a limit ever locks out real visitors before you've had a chance to raise it, use "Reset signup limits" on the same tab to clear the counters immediately.

Yes. Every site keeps its own settings, connects to its own Laposta account, keeps its own log, and sends its own alerts on its own hourly limit.

Nothing beyond what it passes to Laposta. Signups aren't saved on your site. The activity log notes that a form was submitted and whether it worked, and names the form — but never the email address or anything else the visitor typed.

As many as you need. Each is bound to its own Laposta list and has its own fields, messages and settings.

Yes. Wynko bundles integrations for Contact Form 7 and HTML Forms, switched off until you enable one under Wynko → Integrations. Add a checkbox to your existing form and accepted submissions are subscribed to the Laposta list you choose. The system is open, so any plugin or theme can add support for another form plugin. Integrations you didn't get from Wynko are supported by whoever wrote them.

No. Campaign data is cached for 60 minutes by default (you can change this), so a page with the campaigns block on it isn't calling Laposta every time someone visits.

Yes. Wynko only ships the minimum layout CSS and leaves colours, fonts and spacing to your theme. CSS custom properties are there if you want more control. The campaigns block ships no front-end CSS at all.

Yes. [wynko_campaigns] renders the same list as the Wynko: Campaigns block, for places a block won't reach — a classic-editor post, a widget, a template. Every block setting has a matching attribute: count, list, order_by, order, and label, all optional. For example [wynko_campaigns count="5" list="abc123" order="asc" label="name_date"].

The full documentation, covering every screen plus hooks and filters for developers, is at https://getwynko.com/docs/.