Most gifting automation sends one gift at a time, fired by a single event in a CRM. This guide covers a different shape of work. Your team builds a list of people in Clay, decides who to gift, and sends to everyone on the list in a single run.
It suits any team that likes to curate before it sends: sales prospecting, account-based marketing, win-back campaigns, or a batch of customer milestones. A person reviews the list, &Open takes care of the gifts, and every send is recorded against its row in Clay.
Setting this up is a one-time job for your team, done in &Open and Clay with no code. After that, anyone can build a list and send gifts whenever they want.
How it works
At its simplest, this is two stages: build a list, then send. Each one has a part you set up once and a part you repeat every time.
Build the list. Gather and enrich the people you're considering.
Send the gift. Send an invitation to everyone on the list.
Two optional extras build on this: showing each gift's status as it travels, and skipping people you've gifted recently. Both rely on &Open sending updates back into Clay, and both live in the appendix. If you don't need them, the two stages above are a complete workflow on their own.
The everyday loop. Once the setup is done, sending a batch is quick: load your list with the table set not to run on its own, review it, then run. Clay sends each invitation and fills in a redemption link on the row.
What you'll need
Line up these basics before you start. Everything else is built in the stages below.
An &Open campaign for this work. A campaign is the pool of gifts a recipient can choose from. Create it in the &Open platform the same way you set up any campaign. It's not technical, and it isn't done through the API. Note the campaign's ID.
An &Open API key. This lets Clay send gifts on your behalf. Ask your &Open contact for one.
A Clay account on a paid plan, with permission to build tables.
Your contacts, ready to bring in. You'll import these each time you send.
Keep your key safe. &Open API keys have admin-level access. So treat the key like a password. Store it somewhere secure, and share it only with people who need it.
A note on Clay plans and credits. Sending gifts uses Clay's HTTP API actions, and the optional extras use webhooks. Both are available on Clay's paid plans. Running a table also uses Clay credits, so it's worth checking your plan and balance before a large run. See Clay's actions and credits for the details.
Building the list
This stage is where you create the table and, each time, fill it with the people you're considering.
Set up once
Create a new table in Clay with a column each for the gift recipient's first name, last name, and email. You'll add the other columns as you work through the stages below, so the table grows with the guide.
Each time
Before you load anyone in, stop the table running on its own. Clay runs its columns automatically as rows are added, which you don't want while you're still building the list. Turn off auto-update on the table. Nothing will send until you choose to run it.
Then add the people you want to consider. Bring them in from a CSV file, a CRM segment, or another Clay source. Each person becomes a row.
Add any data that will help you decide who gets a gift. Clay can research each person for you with enrichment columns and Claygent, pulling in things like recent LinkedIn activity, how well they fit your ideal customer, or a recent funding round.
Sending the gift
This stage adds the action that sends a gift invitation, then runs it against your list.
Set up once
Add the send action. An action column does something for each row, rather than just holding data. Add an HTTP API action column.
Set it to call &Open's "create a gift invitation" endpoint, POST /gift_requests. The call uses your API key and campaign ID from What you'll need, plus the recipient details from the row. Its body looks like this:
POST <https://api.andopen.co/gift_requests> { "campaign_id": "<your campaign ID>", "recipient": { "first_name": "<row.first_name>", "last_name": "<row.last_name>", "email": "<row.email>" } }Set the action to write the returned id and redemption_url into two new columns, "Gift request ID" and "Redemption URL". Keep the action on manual run, so it never fires while a list is still being built.
Each time
When you're happy with the list, run it. You can run the rows you've reviewed by hand, or set the table to run on a schedule. Each person on the list gets a gift invitation, and the table fills in its ID and a redemption link on their row.
That redemption link is the invitation. Share it with the recipient yourself, or automate sending it straight from the table.
If a row can't send, the reason shows in a "Send error" column, usually a detail that needs fixing such as a missing name or a mistyped email. Correct the row and run it again.
Two more things for larger runs. Add a short delay between rows with Clay's wait actions, so you don't overload the API. And if you'd rather Clay skip people you've gifted recently, set up the optional check in the appendix.
Appendix — optional extras
These extras build on the core flow. They let you see where each gift has got to, and skip people you've gifted recently. Both rely on &Open sending status updates into a Clay table, which uses Clay's webhooks.
Webhooks sit on Clay's paid plans, though receiving the updates themselves doesn't cost credits. If you don't need status or automatic skipping, the core flow is complete without any of this.
Receiving status updates
This is the shared foundation for both extras: a place for &Open to report what's happening to each gift.
Set up once
Add a second table in Clay as a webhook source. Clay gives you a web address to receive data. Pass that address to your &Open contact and ask them to switch on all five gift updates:
gift_request_created, when a gift is sent.gift_request_redeemed, when the recipient chooses their gift.gift_request_dispatched, when the gift is on its way.gift_request_delivered, when the gift arrives.gift_request_cancelled, when the gift is cancelled or expires.
Each update lands as a row in this table. The table records every gift, so it also serves as your gift history for the skip check below.
Coming soon: Gift History API
&Open is building a Gift History API to look up a recipient's gift history directly. Once it's available, you won't need to keep your own history from status updates. Until then, this table is your history. One thing to flag to your team: it only knows about gifts sent after the updates are switched on. If your account has been gifting for a while, those older gifts won't be there at first, so expect more duplicate skips than usual in the first few weeks.
Optional, for your developers: check the signature. With this no-code setup, Clay receives &Open's updates but doesn't check their signature. If you want them verified as genuine, which is worth doing when these sends are sensitive, put a small service between &Open and Clay. It confirms each update really came from &Open, ignores duplicates, then passes it on to your Clay web address. This is the one piece that needs a developer and somewhere to host it. The exact signature check is in the &Open API and Webhooks Customer Reference.
Showing each gift's status
Set up once
On your main table, add a "Gift status" column that reads from the updates table, matched on the gift's ID, and shows the latest status.
Each time
After a run, the "Gift status" column updates on its own as each gift moves along. These are the values you'll see:
Status | What it means |
Submitted | The gift invitation has been sent. |
Redeemed | The recipient has chosen their gift. A good moment to follow up. |
Dispatched | The gift is on its way. |
Delivered | The gift has arrived. |
Cancelled | The gift didn't go through, so it's worth reaching out another way. |
Skipping people you've gifted recently
This check stops the same person being gifted twice in a short space of time. It reads from the updates table, so it needs the setup above in place first.
Set up once
Add an eligibility column to your main table. Use a lookup to find the recipient's email in your updates table, then a short formula to turn what it finds into a result. The rule is: if there's a gift within your look-back window, the row is "skip"; if not, the row is "eligible".
Choose the look-back window that fits your gifting:
Type of send | Suggested look-back window |
Short-cycle (post-meeting follow-up, expansion) | 30 days |
Longer-cycle (deal revival, churn re-engagement) | 60 to 90 days |
Renewal incentive | 12 months |
One-shot win-back | Forever (gift only once) |
Then gate the send action so it only fires when the eligibility column says "eligible". Clay calls this a conditional run. A row is only gifted once it has passed the check.
Each time
You don't need to do anything here. The eligibility column runs as you build the list and marks each row "eligible" or "skip". Expect some skips: that's the rule working. On a large imported list, somewhere around 10 to 30% skipping is normal, especially if your team also sends gifts in other ways. The reason shows on the row.
Related documentation
From Clay:
HTTP API, for calling the &Open API from a column.
Actions and credits, for what a table run costs.
Claygent builder, for building the enrichment and eligibility columns.
Conditional runs, for gating the send on the eligibility check.
Webhooks in Clay, for receiving &Open's status updates.
Table management settings, for turning auto-update on and off.
Sources and CSV import, for getting contacts into the table.
Find your Clay API key, for authenticating your calls.