How to Restrict a Gravity Forms Form with Access Codes, Member Numbers or Postcodes

Most forms on a website are open to anyone who finds them. That is what you want for a contact form, but not for a gala reply form, a members-only workshop, a voucher, a staff survey or a booking form for a service that only covers part of the country. In each of these cases the form should only accept people who have something you gave them: an invitation code, a membership number, an e-mail address on your list or a postcode in your area.

This guide explains the common ways to restrict who can submit a Gravity Forms form, where each of them falls short, and how to check any field against your own list of codes or values with the Gravity Forms Access Codes & Allowed Lists add-on, including single-use invitation codes, member number checks and postcode service areas.

Why restrict a form at all?

Restricting a form is not about secrecy for its own sake. It keeps the entries you get useful and fair:

• Events by invitation: a gala, a launch evening or a private viewing has a guest list. Replies from people who were not invited take seats, meals and staff time.
• Members-only offers: workshops, discounted tickets or resources that are part of a membership should not be open to the public, but asking every member to create a WordPress account is a lot of friction.
• Vouchers and one-off codes: a free class, a gift, a partner offer or an early-bird place that each person may claim once.
• Service areas: a cleaning company, a mobile repair service or a delivery round only covers certain postcodes. Booking requests from outside the area waste everyone’s time.
• Closed groups: a staff survey, a class registration or an exam access form that only a known group should fill in.

In all of these the rule is the same: the value typed in one field must be on a list you keep, and sometimes it may only be used once. Gravity Forms does not have this rule built in.

The usual workarounds and their limits

A password on the form. A single shared password stops casual visitors, but everyone has the same one. You cannot tell who used it, you cannot stop one person sharing it with friends, and you cannot let each guest reply once.

Requiring a login. Making members log in works when they already have accounts. For a gala guest list or a one-off voucher it is far too much: nobody wants to register on a site to reply to an invitation.

A drop-down of allowed values. Putting the member numbers or postcodes into a Drop Down field works for a handful of values, but it shows the whole list to every visitor, it gets unusable with hundreds of entries and it cannot handle postcode prefixes.

Custom validation code. The answer on most support threads is a gform_field_validation snippet with the allowed values typed into a PHP array. It works until the list changes, someone else has to update it, the code must work only once, or two people send the same code at the same moment. A snippet that looks up past entries to block a second use can be beaten by two submissions arriving together, and it cannot give a use back when an entry is deleted.

Checking by hand. Accepting everything and deleting entries that do not belong is the most common approach of all. It means wrong entries trigger notifications, payments and follow-ups before anyone notices.

What a good access-code check needs

• A list you can edit without code: add, generate, import and export codes in the WordPress admin.
• Codes that work a set number of times: once for an invitation or a voucher, 25 times for a class, without limit for a member number.
• A check on the server, before the entry is saved, so a visitor cannot get around it in the browser.
• One winner for each single-use code, even when two people send it at the same moment.
• Expiry dates and personal codes tied to one e-mail address.
• Protection against guessing: a limit on wrong tries and the same message for unknown, used and expired codes.
• Useful data from the list: the guest’s name or table, the member’s name, the zone of a postcode, in the entry and the e-mails.
• A clear view of who used what, with links to the entries and a CSV export.

Setting it up with Gravity Forms

The Access Codes & Allowed Lists add-on adds a Forms → Access Codes page and an Access Codes tab to every form’s settings. Here is the whole set-up for a gala reply form, step by step.

Step 1: create a list

Under Forms → Access Codes, create a list named “Autumn gala 2026” with the type Access codes and 1 use per code. Add your own message, for example “Please check the code on your invitation card.” By default the list shows the same message for every refused code, so nobody can find out which codes exist by trying.

Step 2: add the codes

Generate as many codes as you have invitations, with a prefix such as GALA-. The codes avoid look-alike characters, so GALA-7KQ2-M9XD is easy to read off a printed card. If you already have a guest list in a spreadsheet, import it as CSV instead: a code column, and any other columns you want to keep with each code, such as name and table. An email column makes a code personal, and an expires column gives it a last day.

Step 3: check the field

Open the reply form, go to Settings → Access Codes, choose the Invitation code field and the list. If your codes are personal, also choose the Email field. To store the guest’s table with the reply, map the table column to a Hidden field.

Step 4: test it

Send the form with a wrong code: the message appears under the field and nothing is saved. Send it with a valid code: the reply is saved, the code is used and the Hidden field holds the guest’s table from your list. Try the same code again and it is refused. In the confirmation you can write “Thank you {access_code:name}, see you at table {access_code:table}.”

Member numbers and postcode areas

For a members’ workshop, create a list of the type Allowed values and import your membership numbers with a name column. Allowed values never run out, but each use is counted, so you can see how often each member booked. Put the membership number on page 1 of a two-page form and map the name column to a Member name field on page 2: the member types their number, presses Next and already sees their name on the next page.

For a service area, create another allowed-values list with postcodes or prefixes. LS6* accepts every postcode that starts with LS6, and HG1 2AB accepts exactly that one. Then add a second check on the same form for the ZIP / postcode part of the Address field, with a message such as “Sorry, workshops are only for members in our area.”

Keeping track of codes

Each list shows how many codes are unused, used and used up and how many submissions it has let in. Filter the table by status, search for a code, a name or an e-mail address, follow the links to the entries that used a code, and export the list as CSV, for example to mail the unused codes. You can block a code that was shared too widely, reset a code that should work again, and delete codes you no longer need. When an entry is deleted or marked as spam, its code use is given back automatically.

Tips for codes that work well

• Print codes on invitations in groups of four characters with dashes; visitors may type them with or without the dashes and spaces.
• Use a different prefix per event or campaign, so a code from last year is easy to spot.
• Give codes for paid places an expiry date shortly after the booking deadline.
• For a class or a team, use one code with as many uses as there are places instead of many single-use codes.
• Send codes in a link with ?code=... by enabling dynamic population on the field, so guests do not need to type them at all.
• Keep the same message for every refused code on lists that must stay private, and a clear message on lists where helpfulness matters more.

Frequently asked questions

Do visitors need an account?

No. Anyone with a valid code or value can submit the form; nothing else changes for them.

Can someone see the list in the page source?

No. The list is only read on your server, and the form only learns whether the value it sent is accepted.

What if two guests share one single-use code?

The first submission uses it. The second is refused with your message, even if both arrive at the same moment.

Does it need an outside service?

No. The lists and the checks stay on your WordPress site; the add-on calls no outside service.

Get started

The Gravity Forms Access Codes & Allowed Lists add-on works with Gravity Forms 2.8 and newer. The setup guide covers every setting in detail, including CSV imports, merge tags and who on your team can manage codes. Create your first list, add a check to your form and send a test submission; it takes a few minutes. See the add-on and its plans.