Gravity Forms MailerLite - WordPress Plugin

How to Set Up Gravity Forms MailerLite to Collect Subscribers from WordPress Forms

Gravity Forms MailerLite is not meant to replace MailerLite's standard signup form. It serves a different purpose: when a site already uses Gravity Forms and some of those submissions need to be sent neatly into MailerLite. This guide focuses on the practical side of the integration rather than a product overview: preparing the account, connecting the API key, creating a feed, mapping fields, sending subscribers to groups, using conditional logic, verifying the outcome, and troubleshooting issues.

The core idea is simple: a visitor fills out a form on the site, Gravity Forms saves the entry, and the add-on sends the required data to MailerLite through the configured feed. In practice, the outcome depends on small details: the correct email field, a valid API token, the selected group, the custom field structure, user consent, and whether the conditional logic actually fired. If any of those pieces are chosen carelessly, the integration may look like it works while subscribers end up in the wrong place, fields stay empty, or the feed does not run at all.

This guide is for site owners, marketers, or WordPress administrators who need more than just "turning on the integration." The goal is a setup you can actually verify: the subscriber appears in the correct group, additional fields are filled in, unnecessary submissions are not sent, and edge cases can be reviewed quickly through logs and entry data.

Where This Integration Is Actually Useful

The most obvious use case is a dedicated newsletter signup form. But Gravity Forms MailerLite is useful in a broader range of situations: it lets you add email marketing to forms that already serve a primary purpose on the site. That might include webinar registration, consultation requests, content download forms, client questionnaires, event signups, or contact forms with a separate newsletter consent checkbox.

Built-in MailerLite forms are convenient when you need a simple signup flow without any complex WordPress-side logic. Gravity Forms is stronger when the form needs to collect more context: first name, last name, company, product interest, city, inquiry type, consent for different communication channels, or submission source. The add-on passes that data into MailerLite through field mapping, and MailerLite then uses groups, custom fields, and automations.

What the Feed Actually Does

In Gravity Forms terminology, a feed is the rule that processes a successful form submission. A single form can have one or more feeds for different integrations. In the MailerLite case, the feed answers four questions:

• Which MailerLite group the subscriber should be added to.
• Which Gravity Forms field contains the email, first name, and last name.
• Which additional form fields should be sent into MailerLite custom fields.
• Under what conditions the feed should run, if conditional logic is enabled.

That is important to distinguish from Gravity Forms notifications. A notification sends an email to an administrator or the user, while a feed sends data to an external service. So the situation where "the email arrived, but the subscriber did not appear" is not contradictory: notifications and the MailerLite integration are handled by different mechanisms.

When Not to Start with This Integration

Gravity Forms MailerLite may be unnecessary if the site only needs one simple signup form and the entire workflow is already easy to manage directly in MailerLite. It also will not solve full CRM workflows, advanced email analytics, or migration of a historical subscriber database. For bulk contact imports, it is better to use MailerLite's own tools rather than trying to push old records through a form.

There is also a separate limitation for MailerLite Classic. The official Gravity Forms documentation states that the add-on does not support Classic accounts. If the site is tied to an older MailerLite Classic account, the first step is to address migration to the newer version of MailerLite or choose a different integration route. There is no point regenerating the key repeatedly if the account itself belongs to an unsupported product branch.

Who Gravity Forms MailerLite Is Best For, and When Another Approach Makes More Sense

This plugin is the best fit for sites where Gravity Forms is already the main form builder. In that case, the integration does not introduce a new interface for visitors, does not force the team to maintain two different forms for the same task, and lets you keep using familiar Gravity Forms features: conditional fields, confirmations, notifications, the editor block, shortcodes, and saved entries.

A strong use case is a site where the subscription is built into a meaningful action. For example, a user registers for an online event and selects a topic of interest; that person can then be added to a "Webinars" group while the topic is saved into a custom field. Or a visitor downloads a checklist, leaves a company name and job role, and MailerLite receives not just the email address but also useful data for future segmentation.

Good Fit

• WordPress sites where Gravity Forms is already installed and actively used.
• Teams that need to send more than just an email address to MailerLite, such as first name, last name, company, interest, or lead source.
• Projects where a subscription should depend on a consent checkbox, topic selection, or another form field.
• Marketers who want to split subscribers into MailerLite groups right at the form submission stage.
• Agencies building a repeatable setup for client sites without manual CSV exports.

May Not Be the Best Fit

• Sites without a Gravity Forms license and without a real need for an advanced form builder.
• Projects still on MailerLite Classic, where migration to the newer MailerLite platform is not yet possible.
• Workflows that require more than adding a subscriber to a group, such as complex two-way CRM updates.
• Cases where subscriptions should be triggered by store events, account activity, or an external app rather than a form.

If you are unsure, start with a different question than "Which plugin should I install?" Ask instead: "What data should land in MailerLite after the form is submitted?" If you only need an email address from one form, the solution will be straightforward. If you need groups, fields, consent, and multiple workflows, Gravity Forms MailerLite becomes much more valuable.

What to Check Before Installation and Setup

Preparation saves more time than it seems. Most problems with form and email service integrations are not caused by installing the add-on itself, but by an unprepared data structure: the required group does not exist, the custom field has not been created in MailerLite, the form has no separate consent checkbox, or the API token was copied incompletely.

Check the WordPress and Gravity Forms Basics

In the WordPress admin area, make sure Gravity Forms is installed, activated, and that the form you plan to use is already saving entries without errors. Before connecting MailerLite, it is worth sending a test submission and opening the record under Forms - Entries. That helps you separate form problems from integration problems.

If the form is embedded inside a complex popup, page builder tabs, or a cached block, test it on a regular page without extra wrappers. Sometimes visitors see a successful submission message, but popup scripts or Ajax behavior interfere with the confirmation display. That does not necessarily break the MailerLite feed, but it makes troubleshooting harder.

Prepare MailerLite

In MailerLite, create the group in advance where the subscriber should be added. Groups in MailerLite are meant for managed contact lists: one subscriber can belong to multiple groups, and deleting a group does not automatically delete the contact itself. That is why group names should be clear for the team, such as "newsletter-main," "webinar-leads," "download-checklist," or another internal naming format.

If you need to send additional data, create the custom fields before setting up the feed. For example, a field for company, topic of interest, or selected plan. Gravity Forms shows available MailerLite fields inside the mapping settings, so having the structure prepared ahead of time reduces the risk that an administrator picks the wrong key or leaves a field empty.

Decide How You Will Handle Consent

For a dedicated signup form, consent is usually obvious: the person is filling out the form specifically to subscribe. For a contact form, request form, or event registration, it is better to add a separate checkbox with clear consent wording. That checkbox can then be used in the feed's conditional logic: send data to MailerLite only if the user explicitly opted in.

Practical check: before installing the add-on, open the form and list which fields truly need to go into MailerLite. Email is required, first and last name are helpful, and the rest should only be added if they will actually be used in segmentation, emails, or automations.

Do Not Send Extra Data

Form fields may contain personal data that email marketing does not need: detailed comments, internal order numbers, attachments, internal notes, IP addresses, or technical parameters. Do not send everything over "just in case." The less unnecessary data you push to an external service, the easier it is to manage consent, privacy, and database quality.

How to Design the Form Before Setting Up the MailerLite Feed

A weak integration usually starts not in the MailerLite settings, but in the form itself. If the form collects data in a messy way, the feed will simply pass that mess along. That is why it is worth designing the form before creating the feed: which fields the user sees, which fields are hidden, which values MailerLite actually needs, which should stay only in the entry, what counts as consent, and what the user should see after submission.

Gravity Forms is useful because it lets you build not just a set of fields, but a compact workflow. That matters especially for subscriptions. A person should understand what they will get after submitting, why you are asking for extra data, and why the consent checkbox is separate from the main request. The more transparent that flow is, the fewer complaints, accidental subscriptions, and messy segments you will end up with.

Email Field and Input Quality

For email, always use Gravity Forms' dedicated email field. A plain text field may seem more flexible, but it creates more errors: a visitor may enter an address with a typo, an extra space, extra text, or even a comment. The email field does not replace MailerLite's own address verification, but it gives you the first layer of validation before the feed is sent.

If the form has multiple steps, do not hide the email field too deep in the flow without a reason. The user should understand that they are leaving an address for follow-up communication. In more complex forms, it helps to place the email field near the value statement: access to the material, event registration, a consultation, or a launch notification. That reduces the feeling that the subscription was added unexpectedly.

First Name, Last Name, and Personalization Without Unnecessary Friction

A first name helps personalize emails, but it does not always need to be required. For a simple content download, email and first name may be enough. For a consultation, request form, or event registration, asking for a name is usually appropriate. Last name is needed less often: if it is not actually used in MailerLite, do not force users to fill it in just to make a table look nicer.

If you use Gravity Forms' compound Name field, check which internal parts of the field are available during mapping. In the feed, it is important not to mix up first name and last name. That kind of error does not technically break the integration, but it damages data quality: emails address people awkwardly, and name-based filtering becomes useless.

Using the Consent Checkbox as a Control Field

The consent checkbox is best implemented as a separate field rather than buried inside general form copy. In a request form, a user may want a response from a manager without wanting marketing emails. The same can apply to a content download form: the user gets the file, but the subscription should be explained separately if you plan to continue emailing them.

In the feed, the checkbox becomes a control switch. If the field is selected, Gravity Forms MailerLite sends the data to the group. If it is not selected, the record stays in Gravity Forms, the team may still receive a notification, but MailerLite does not get the subscriber. This is one of the most important settings for maintaining a clean list and a clear user experience.

Hidden Fields and Subscription Source Tracking

Hidden fields are useful when the same action needs to be distinguished by page, content asset, or campaign. For example, the same form might appear on several pages with different checklists. A hidden field can store a value like seo-checklist or speed-guide, which you can then map to a MailerLite custom field.

But hidden fields should not turn into a storage bin for technical clutter. Only pass values that will genuinely be useful: the content asset name, form source, interest type, or internal campaign code. If the team cannot explain where that field will be used in MailerLite, it is better not to send it.

Post-Submission Confirmation

The confirmation in Gravity Forms does not directly affect the MailerLite feed, but it does affect user trust and support. After submission, the user should see a clear next step: "Check your inbox," "Your download link is below," or "We have sent your request to the team." If MailerLite is used for a welcome series, do not promise an instant email until you have tested the automation with a new address.

For a lead magnet, it is often smart to split the two outcomes: the on-site confirmation shows the link or a brief instruction, while MailerLite adds the person to the group for the follow-up email sequence. That way, the user does not depend on delays in an external service, while your list still grows as intended.

Installing the Add-On and Connecting the API Key

The official add-on is installed from the Gravity Forms ecosystem. In a typical setup, the administrator opens Forms - Add-Ons, finds the MailerLite Add-On, installs it, and activates it. Once activated, a MailerLite tab appears in the Gravity Forms settings.

The actual connection is made using a MailerLite API key. In the current version of MailerLite, the key is created in the Integrations section, where a new token is generated for the MailerLite API. The token is shown only once, so it should be copied in full immediately and stored in a secure secrets manager. Do not send the API key in contractor chats or paste it into public documents.

Path in Gravity Forms

1. Open the WordPress admin panel using an account that has permission to manage Gravity Forms settings.
2. Go to Forms - Settings.
3. Open the MailerLite tab.
4. Paste the full API key into the API Key field.
5. Click Save Settings.

After saving, Gravity Forms documentation expects to show a green check next to the key field. That is not just a decorative mark: it indicates that the site was able to connect to MailerLite and the key was accepted. If you see a red indicator or an error message instead, it is too early to move on to feed creation.

What the Red Indicator Means

Most often, the problem is caused by an incomplete token, an extra space added during copying, a token from a different account, or a MailerLite Classic account. Another possibility is temporary inability to reach the external API from the site's server. Check the token in MailerLite, generate a new one if needed, and paste it in without any extra characters.

If the connection does not appear at all, go back to the add-on installation: the MailerLite tab only exists after the relevant component has been activated. If the tab is there but the settings cannot be saved, check the user's permissions and the general state of Gravity Forms.

Safe Rollback

If you are testing the integration on a live site, create a separate test group in MailerLite and a temporary form or a copy of the form. After testing, you can delete the test feed or disable it without touching the main form. If the API key was exposed by mistake, do not try to "just ignore it": create a new token in MailerLite, replace it in Gravity Forms, and delete the old one.

Creating a MailerLite Feed: Group, Email, and Core Fields

Once the API key is connected successfully, the work moves to the level of a specific form. Open the form you want, go to its settings, and select MailerLite. Then click Add New to create a new feed. This is where you define what should happen after that form is submitted successfully.

The first field is the feed name. Do not call it simply "Feed 1." A good name answers the question of why it exists: "Newsletter opt-in," "Webinar group," "Checklist download," or "Client request with consent." If the form ends up with several integrations a few months from now, a clear name will save time during troubleshooting.

Choosing the Group

The MailerLite Group field determines where the subscriber will be added. If the group you need is missing from the list, check whether it was created in MailerLite and whether the correct account is connected through the API key. A group is not just a folder. It often triggers segmentation, campaigns, or automations, so choosing the wrong group can lead to the wrong emails being sent.

Email, First Name, and Last Name

The Email field is required. Choose the actual Gravity Forms email field, not a general text field where the visitor is only "supposed" to type an address. The dedicated email field provides basic format validation and makes the setup clearer for the next administrator.

First Name and Last Name are not always required, but they are useful for personalization. If the form uses Gravity Forms' compound Name field, select the correct part carefully. A common mistake is mapping the full name into first name or leaving last name blank even though the form collects it.

Minimum Working Configuration

After saving the feed, submit a test entry through the form. Do not stop at the "form submitted" message: open MailerLite and find the test email in the group. Then open the entry in Gravity Forms and compare the values. The critical verification point is this: one test email appears in the correct MailerLite group, and the Gravity Forms entry is saved without errors.

Mapping Custom Fields Without Losing Meaning

Custom fields are one of the main reasons to use Gravity Forms instead of a simple embedded form. They let you send useful context to MailerLite: company, job role, city, selected topic, service type, lead source, or any other field that genuinely improves your email marketing. But this is also where noisy data often starts creeping in.

In the MailerLite feed settings, Gravity Forms documentation describes the Key / Value block. Key is selected from MailerLite fields, and Value comes from Gravity Forms fields. If you need another pair, you click the plus icon. In practical terms, this is a mapping table: "put this value from the form into this MailerLite subscriber field."

How to Choose Which Fields Are Worth Sending

Before mapping, split your fields into three groups. The first is required for subscriptions: email, first name, last name. The second is useful for segmentation: interest, category, city, company, role. The third includes fields that are better left only in the Gravity Forms entry: long comments, attachments, internal operational data, or a detailed request containing sensitive information.

MailerLite custom fields may have types such as text, number, or date in the API documentation. Do not push arbitrary text into a numeric field or an unclear date string into a date field. Even if the interface allows the setup to be saved, downstream filtering and automations may behave unpredictably.

Long Text Limits

The Gravity Forms documentation for the MailerLite feed specifically notes one limitation: when data is sent into a MailerLite text custom field, it is truncated to the first 1024 characters, while the full value remains in the Gravity Forms entry. In a typical signup form, that is not a problem. But if you try to send a long "Comment" or "Tell us about your project" field, part of the text may never reach MailerLite.

Practical takeaway: keep long-form responses in Gravity Forms, your CRM, or a help desk system. Send only short values to MailerLite that are actually useful for segmentation and email personalization.

A Practical Mapping Pattern for a Lead Magnet

For a content download form, you can use a structure like this:

• Email - the form's email field.
• First Name - the user's first name.
• custom field lead_magnet - the content asset name or a hidden form field.
• custom field interest - the topic selected by the user in radio buttons or a dropdown.
• custom field source_page - a hidden field or fixed value, if that mechanism already exists in the form.

This setup keeps the subscriber profile from becoming overloaded while still supporting relevant email flows. For example, one group can store everyone who downloaded content, while the interest field clarifies what they should hear about next.

MailerLite Groups and Conditional Logic: How to Avoid Sending Everyone into One List

MailerLite groups help organize subscribers both manually and through integrations. In the context of Gravity Forms MailerLite, there are usually two workable approaches. The first is one form feeding one group, while differences are stored in custom fields. The second is one form with multiple feeds, each sending subscribers to a different group, with conditional logic deciding which feed should run.

Both approaches are valid, but they fit different needs. If you simply want to know which topic a person is interested in, a custom field is often cleaner. If a group triggers a specific automation or campaign, it is better to send the subscriber directly into that group at the form level.

Consent Checkbox Workflow

The most practical use of conditional logic is to avoid sending everyone into MailerLite by default. Add a checkbox such as "I want to receive helpful emails and updates." Then enable Enable Condition in the feed settings and create a rule so the feed only runs if the checkbox is selected.

This matters especially for contact forms. A person may submit a question through the form without agreeing to email marketing. Gravity Forms will save the entry and send the team notification, but the MailerLite feed should not run without consent. That setup is cleaner both for the user and for your mailing database.

Different Groups Based on Interest

Suppose a webinar registration form includes a field called "Topic of Interest": SEO, site speed, or security. You can create three groups in MailerLite and three feeds in Gravity Forms. Each feed selects its own group and includes a condition such as running only if the topic equals the matching value. As a result, one form routes subscribers into different groups without any manual sorting.

The key here is avoiding conflicting rules. If conditions overlap, one user may end up in multiple groups. Sometimes that is expected, since MailerLite allows subscribers to belong to several groups. But if you need exactly one group, check the field values and the "all/any" logic carefully.

When to Use a Group vs. a Custom Field

The best Gravity Forms MailerLite setup is usually not the most complicated one. In many cases, one group, a few short custom fields, and one consent condition are enough. Add multiple feeds only when different groups serve a real purpose.

Repeat Signups, Existing Contacts, and List Hygiene

After the first tests, the next question is what happens if the person already exists in MailerLite. That is a normal situation: the visitor may have subscribed through another form, an import, a MailerLite landing page, or a previous campaign. This article cannot promise one universal behavior for every account, because the outcome depends on MailerLite itself, the group, automations, and the state of the specific subscriber. But you can still design the validation process correctly.

MailerLite groups allow one subscriber to belong to multiple groups. So a repeat form submission does not necessarily mean a "duplicate" in the usual sense. One email may already exist in the database and then be added to a new group as well. That is useful when groups reflect interests or acquisition sources. But if the team treats a group as the only "list," that behavior can be surprising.

Test a New Email and an Existing Email Separately

For a proper check, use two addresses. The first should be new to MailerLite, so you can see a clean subscriber creation. The second should already exist in the database, so you can see how groups and fields are updated on a repeated submission. Compare not just whether the contact exists, but also the state of the custom fields. Some fields may be updated with a new value, and that is only good if you expected that behavior in advance.

For example, if the interest field stores the most recently selected interest, another submission with a new topic may overwrite the previous value. If you need a history of all interests, a custom field is not the best place to keep it. In that case, groups, separate tags where supported by the platform, or Gravity Forms entries are a better fit.

Do Not Use One Group for Every Purpose

A typical mistake is creating a single group called "Subscribers" and sending every form into it. At first, that feels convenient, but later it becomes impossible to tell why someone entered the database, what they downloaded, what they consented to, or which email sequence actually fits them. It is better to have one main mailing group plus separate groups or fields for important sources, if those distinctions are truly used.

At the same time, do not swing too far in the other direction and create a group for every button. MailerLite groups should help manage communication. If a group is not used in campaigns, automations, filters, or reporting, a source field may be enough.

How to Avoid Accidentally Triggering the Wrong Sequence

If a MailerLite automation is triggered by a group, verify that before connecting the live form. Create a test group or temporarily disable the automation, submit the form a few times, make sure the fields and groups are filling correctly, and only then switch to the real workflow. Otherwise, one feed mistake can send users into the wrong welcome series.

For more complex forms, it helps to launch the integration in a "soft" mode first: add subscribers to a test group, review the data for a few days, and then switch the feed to the production group. This approach is especially useful on sites with steady traffic, where even one hour of incorrect settings can create dozens of bad subscriptions.

Deleting or Disabling a Feed

If a workflow is no longer needed, it is better to disable the feed than to leave it behind with an unclear name. Before deleting it, record where it was sending data and which fields were mapped. The Gravity Forms entries will still preserve the submission history, but the integration settings may be needed later for recovery or audit purposes.

Whenever you change the group or the mapped fields, send a fresh test submission. Do not rely on older records: they reflect the previous state of the form, not the current feed behavior. A setup is only verifiable when it is confirmed by a new submission with clear test values.

Practical Example: Checklist Download Form with Interest-Based Segmentation

Let us walk through a concrete use case. A site has a page offering a useful checklist. The user enters a name and email, chooses a topic, consents to receive emails, and gets a confirmation with a link to the asset. In MailerLite, that person should be added to the "download-checklist" group, and the selected topic should be saved into the interest custom field. If consent is not checked, the entry stays in Gravity Forms, but the subscriber is not added to MailerLite.

Goal

Build a working form where visitors can download the asset while the team gets a clean subscriber list with meaningful segmentation. This is not just about collecting email addresses. The real outcome is that MailerLite shows the person came from a specific lead magnet, selected a particular interest, and can receive a relevant email sequence.

Preparation

• The download-checklist group has been created in MailerLite.
• The interest custom field has been created in MailerLite as a text field.
• The lead_magnet custom field has been created in MailerLite, if you want to store the asset name.
• Gravity Forms is installed in WordPress and the MailerLite Add-On is activated.
• The API key is saved under Forms - Settings - MailerLite and shows a green check.

Form Fields

Create or open the Gravity Forms form. Add an email field, a name field, radio buttons or a dropdown for the topic of interest, a consent checkbox, and, if needed, a hidden field containing the asset name. The checkbox label should be clear to the user rather than written for internal use, for example: "I want to receive emails related to this resource."

Feed Setup

1. Open the form and go to Settings - MailerLite.
2. Create a new feed named Checklist opt-in.
3. Select the download-checklist group.
4. Map Email to the form's email field.
5. Map First Name to the name field.
6. In the custom fields block, choose the interest key and map it to the topic field.
7. If a hidden field is used, map lead_magnet to that value.
8. Enable Enable Condition and set the condition so the consent checkbox must be selected.
9. Save the feed.

Verifying the Outcome

Submit two test entries. In the first, check the consent box. In the second, leave it unchecked. For the first submission, the subscriber should appear in the MailerLite group with the interest field filled in. For the second, the entry should be saved in Gravity Forms, but the subscriber should not be added to MailerLite. This is a simple but critical test: it proves that the feed is not sending every visitor into the list indiscriminately.

Quick takeaway: a successful setup is not just a green check next to the API key. It is only working when different test submissions produce the expected differences inside MailerLite.

Post-Launch Verification: Entry, Group, Fields, and Automation

Once the form is live, do not stop after a single test submission. An email service integration should be checked as a chain: the public form, the Gravity Forms entry, the feed, the MailerLite subscriber profile, the group, the custom fields, and any follow-up automation. If you only verify the first or last step, it is easy to miss where the issue actually starts.

Check in Gravity Forms

Open Forms - Entries and locate the test record. Make sure the entry contains the email, name, consent, and every field that should be sent to MailerLite. If a field is already empty here, MailerLite cannot receive the correct value. In that case, the fix belongs in the form, its field-level conditional logic, or the embedding method, not in the feed.

Check in MailerLite

In MailerLite, find the test email among your subscribers. Verify that it belongs to the correct group. Then open the subscriber profile and review the custom fields. If the group is correct but a field is empty, the problem is almost always in the Key / Value mapping or the selected field type.

Check the Automation

If the group triggers a MailerLite automation, verify not just the presence of the subscriber, but whether the workflow itself starts. In some cases, the person may already have been a subscriber, and being added to the group again can behave differently from adding a brand-new contact. MailerLite also has re-entry settings for some triggers, so test the workflow separately with a new address and with an existing one.

Check the Public Page

After placing the form on the page, test it in a normal browser session without admin rights. If caching, a popup, or a page builder is involved, test on the actual public page. Make sure the confirmation is clear, repeated submissions do not break the interface, and users do not see internal-only fields.

The expected live state is this: the form submits without a visible error, the entry is saved, the subscriber appears in the correct group, the required custom fields are populated, and the consent rule genuinely affects whether the feed runs.

Privacy, Performance, and Maintainability

Gravity Forms MailerLite is usually not a heavy element on a public page. The main load happens during form submission processing and data transfer to the external service. But the quality of the implementation still affects ongoing site support: you can build one clear form with one understandable feed, or you can end up with a stack of hidden fields, overlapping conditions, and vaguely named groups.

Privacy and Data Minimization

Only send what MailerLite actually needs for campaigns, segmentation, or automation. If a field is not used in emails, filters, or reporting, it probably does not belong in the subscriber profile. Be especially careful with long messages, files, internal comments, and operational data.

If the site serves audiences where consent is especially important, use a separate consent field and feed-level conditional logic. Do not hide a subscription inside generic form wording. The user should understand exactly what will happen after submission.

Maintainable Configuration

Give the feed a clear name, and name MailerLite groups so that someone other than the current administrator can understand them. A few months later, the team may no longer remember how "Group 4" differs from "Leads New." Good feed and group names are part of your documentation.

When to Enable Logging

Gravity Forms supports logging for both the core plugin and add-ons. Logs are useful when a subscriber does not appear, the API returns an error, or the feed behaves inconsistently. But logs may contain personal data, so they should not be left enabled permanently. Turn logging on for troubleshooting, reproduce the issue, save the necessary output, then disable logging and clear the logs.

If the site uses a role management plugin and the administrator cannot see the logging section, check the user's permissions. That is a common organizational issue: the integration works, but the person diagnosing it does not have access to the needed logs.

Common Gravity Forms MailerLite Problems and How to Troubleshoot Them

Below are issues that are specific to the combination of the form, feed, API key, MailerLite groups, and conditional logic. The cleanest way to troubleshoot is top-down: first the form and entry, then the feed, then MailerLite, then logs and background tasks.

The API Key Does Not Save or There Is No Green Check

Symptom: after saving the MailerLite settings in Gravity Forms, the green check does not appear, an error is shown, or the tab still looks like the account is not connected.

Cause: the token was copied incompletely, pasted with an extra space, created in a different account, deleted in MailerLite, or the account is Classic. A temporary connectivity issue between the server and the MailerLite API is also possible.

What to check: generate a new token in MailerLite, copy it using the copy button, paste it into Forms - Settings - MailerLite, and save. Verify that the account is on the newer version of MailerLite rather than Classic.

How to fix it: replace the key, reconnect the settings, and test again. If the issue remains, enable logging and check whether the API request error is visible.

The Subscriber Does Not Appear in MailerLite Even Though the Form Was Submitted

Symptom: the user sees the confirmation, the entry is saved, the admin notification arrives, but the subscriber is missing from the MailerLite group.

Cause: the feed was never created, is disabled, is attached to another form, the conditional logic did not pass, the email field is mapped incorrectly, or the entry was marked as spam. Under Gravity Forms' general rules, feeds are not processed for spam entries.

What to check: open the settings for the specific form, not the global settings. Make sure the feed is active, the email is mapped from the correct field, the consent condition is actually met, and the entry is not in spam.

How to fix it: correct the mapping, temporarily disable the conditional logic for testing on a separate form copy, or create a new test feed with the minimum settings. If the minimal feed works, add the conditions back one at a time.

The Subscriber Lands in the Wrong Group

Symptom: the contact is created, but it shows up in a different group or in multiple groups at once.

Cause: the wrong MailerLite Group was selected, the form has multiple feeds with overlapping conditional logic, or MailerLite already has rules or automations that add the subscriber to extra groups.

What to check: the form's feed list, the conditions for each feed, the group names in MailerLite, and the test subscriber's profile. Use a brand-new email address for testing, one that has never been in the database before.

How to fix it: refine the conditions, rename feeds for clarity, and disable unnecessary feeds. If the subscriber should go into only one group, the rules must be mutually exclusive.

Custom Fields Are Empty or Data Gets Truncated

Symptom: the email and name are sent correctly, but the additional fields in MailerLite are empty, incorrect, or contain only part of a long text.

Cause: the Key / Value pair is wrong, the MailerLite field was not created before the feed was configured, the selected field type does not fit, or a long text is being sent. For text custom fields, the documentation notes truncation at 1024 characters.

What to check: open the entry and confirm that the source field is actually filled in. Then open the feed and compare which MailerLite key is selected and which Gravity Forms field is being sent as the value.

How to fix it: create the required custom field in MailerLite, update the mapping, and test again. Do not send long comments into MailerLite in full; keep them in the Gravity Forms entry.

MailerLite Classic Account Does Not Work

Symptom: the API key appears to be correct, but the connection or feed still does not work, and you see mentions of Classic in documentation or discussions.

Cause: the official Gravity Forms MailerLite Add-On does not support MailerLite Classic. The newer MailerLite API and the Classic API are different product branches.

What to check: the MailerLite account version and the migration documentation. If the account was created long ago, confirm whether it is still using Classic.

How to fix it: migrate to the newer MailerLite platform or choose an alternative integration path that explicitly supports the required account version. Do not waste time trying to fix this by repeatedly reconfiguring the feed.

The Feed Runs Inconsistently or with Delays

Symptom: some submissions appear in MailerLite only after a delay, while others do not appear at all without any visible error.

Cause: Gravity Forms background tasks, external API requests, server limitations, blocked loopback requests, security conflicts, or temporary API responses.

What to check: Gravity Forms System Status, WordPress Site Health, and the Gravity Forms Core and add-on logs. Gravity Forms documentation on background processing recommends reviewing background task handling and response codes.

How to fix it: enable logging only while troubleshooting, submit a test form, review the log entries, and then disable logging. If the issue is related to server requests, give your hosting provider the specific response code and the exact test time.

When Gravity Forms MailerLite Is the Right Choice

Gravity Forms MailerLite is worth using if you want to turn a WordPress form into a controlled entry point for email marketing: sending subscribers into MailerLite, preserving useful fields, respecting consent, and verifying the outcome without manual exports. It is especially strong when the form already collects meaningful context rather than just an email address.

Before launch, verify three things: the MailerLite account must be compatible, the API key must show a green check in the settings, and the feed for the specific form must have a clear group, correct email mapping, and a consent condition if needed. Then run tests with different submission variants and compare the entry with the subscriber profile.

If you are ready to test the integration on your own site, you can download Gravity Forms MailerLite, install the add-on, and first test it on a separate form or a test group. That is safer than connecting it directly to a live form with a high volume of submissions.

The real measure of a successful setup is not the installation itself, but a predictable chain: the visitor submits the form, Gravity Forms saves the entry, MailerLite receives only the necessary data, the subscriber lands in the correct group, and the team knows exactly where to look if one step fails.