Your Laposta signup forms, on your own site.

The safest setup, and the one we recommend, is one line in wp-config.php:

define( 'WYNKO_API_KEY', 'your-laposta-api-key' );

A key defined this way never enters your database, so it can’t leak through a backup, a stray export, or a database-level breach. If a constant is set, it always wins — Wynko won’t let a saved value quietly shadow it. On multisite, suffix the blog ID (WYNKO_API_KEY_3) to give one site its own key.

Where the sodium PHP extension is available and your site has real WordPress security salts, the key is sealed with authenticated encryption before it’s written to the database. A raw database export or a SQL-injection read doesn’t hand over a usable key.

This protects the database on its own. It does not protect against someone who can also read wp-config.php, because your salts live there too. If you rotate SECURE_AUTH_KEY, previously sealed keys become unreadable by design, and the settings screen tells you exactly that rather than sending garbage to Laposta.

If your server has no sodium extension, or you’re still running WordPress’s placeholder salts, the key is stored as plain text and the settings screen says so plainly.

Not just the key. Cache duration, log level, rate-limit window and caps, and error alerts can all be set from an environment variable or a wp-config.php constant. Environment variables outrank constants, constants outrank the settings screen, and each tab shows which one is in charge so it’s never ambiguous where a value came from.

That means staging and production carry their own configuration with your deployment, instead of someone remembering to click through a settings screen on every site.

By default one visitor can submit 15 signups and one form can accept 400, within any rolling 10-minute window. All three numbers are adjustable, and there’s a “Reset signup limits” button if a limit ever locks out real visitors before you’ve had a chance to raise it.

The per-visitor cap is the one to raise if a shared office, school or NAT gateway sends real traffic from a single address. The per-form cap is a backstop, not a first line of defence — keep it well above your real traffic.

The activity log records key checks, connection checks, syncs and signups at whatever level of detail you set. It never contains your API key, and signup entries never contain anyone’s email address or answers. Filter it on screen or download it as a .txt to attach to a support request.

There’s a system report too — a health check of WordPress, PHP, your database, PHP modules and your server, each flagged against what Wynko is tested with. It warns you about anything unusual and never blocks you.

Every site in the network has its own settings, its own Laposta account, its own log and its own alerts on its own hourly limit. Uninstalling cleans up after itself across the whole network.

Every outgoing API call, campaign fetch, form submission and log entry fires a wynko_* action or filter. Add a header to every Laposta request, pull the API key from your own secrets manager, or forward error-level log entries into your own alerting stack — no core edits.

add_filter( 'wynko_api_key', fn( $key ) => my_secrets_manager()->get( 'laposta_key' ) ?: $key );

See the full reference in the hooks and filters docs.

Wynko ships bridges for Contact Form 7 and HTML Forms — off until an admin switches them on under Wynko → Integrations. The same registry is open to your own code: implement Wynko\Integrations\Integration, add it to the wynko_register_integrations filter, and your bridge appears on that screen with its own settings, version and docs link.

add_filter( 'wynko_register_integrations', fn( $list ) => [ ...$list, new My_Wynko_Integration() ] );

Your integration writes to Laposta through Wynko\Api\Subscribers::create(), reusing Wynko’s key resolution and transport. See Integrations for the full contract and a getting-started walkthrough.