Zapier and Make automations for USDC shop sales.

What Fianto sends to Zapier or Make

Fianto sends each event as one flat JSON object, so Zapier and Make can map every field without a path. Every key is always present, with null when there is nothing to put in it, so a mapping built from one event works for the next. A monthly membership bought in a shop called quillfern (a made-up example; the ids are shortened) arrives like this:

{
  "event": "purchase.paid",
  "id": "evt_6b0e2f...",
  "created_at": "2026-10-15T09:12:44.000Z",
  "shop": "quillfern",
  "shop_url": "https://quillfern.fianto.xyz",
  "product": "Field notes membership",
  "product_id": "fian_prod_...",
  "price": "12",
  "amount_paid": "12.01",
  "currency": "USDC",
  "buyer_email": "reader@example.com",
  "order_id": "shop_...",
  "subscription_id": "fian_sub_...",
  "interval": "month",
  "paid_at": "2026-10-15T09:12:44.000Z"
}

The amounts differ from Fianto's developer webhooks, which send USDC base units ("12000000"). Here they are ready to paste into a spreadsheet. On subscription.ended, amount_paid is what the buyer last paid, which a discount code can make lower than the list total.

Connect a Zap or a Make scenario in five steps

1. In Zapier, start a Zap with the "Webhooks by Zapier" app and its Catch Hook trigger. In Make, add a "Custom webhook" from the Webhooks app. Copy the URL each one gives you.
2. In the Fianto dashboard, open your shop's settings and find Connect an app. Paste the URL under Webhook URL and press Connect. Fianto asks for your password and two-factor code, because the app will receive every buyer's email.
3. Press Send a test. Fianto posts a sample purchase.paid (product "Sample product", order_id "shop_test", buyer "buyer@example.com") marked with "test": "true", and shows Delivered or the reason it failed. You get 10 test sends an hour.
4. Back in Zapier or Make, map the fields to your action. Add a filter that drops events where test exists, so the sample never grants anyone access. Real events never carry it.
5. On every product that grants access, set Buyer email to Required. With an app connected, the editor flags a membership product that does not: "Your connected app needs the buyer's email to give access. Set Buyer email to Required."

Fianto accepts only https://hooks.zapier.com/... and Make's hook hosts (hook.make.com and its eu1, eu2, us1 and us2 zones). Any other URL is refused with "Paste the webhook URL from Zapier (https://hooks.zapier.com/...) or Make (https://hook.eu1.make.com/...)." The path of the URL is the hook's only secret, so after saving, the dashboard shows just the host and a six-character ID.

Four automations worth building

The dashboard pitches the feature in one line, "Open access automatically in your course or membership tool," and that is the strongest use. The rest are bookkeeping and alerts.

Zapier and Make each list the apps they connect to: browse Zapier's webhook integrations or Make's integrations. For access, match members on subscription_id where you can store it, not only on the email: a buyer may type a different address next time. A full course setup, from pricing to delivery, is in selling an online course for USDC.

Which sales the connection never sends

The connection sends shop purchases and nothing else. Plan around these gaps before you promise a customer that access opens or closes on its own:

• Payment link and API sales. A sale through a USDC payment link or your own checkout integration sends nothing to Zapier or Make.
• Renewals. purchase.paid fires once per purchase, at the first charge. A monthly subscriber who renews ten times produces one event.
• Failed renewals and cancellations in progress. There is no past-due or cancel-scheduled event here. A subscriber whose renewal fails stays in your tool until the subscription ends, which happens after the fourth counted failed attempt, about a day after the period boundary. A cancelled subscription runs to the end of the paid period, then subscription.ended fires.
• The past. An app connected today is never sent purchases from before it was connected.
• Emails to buyers. Fianto sends the shop buyer one email after a paid purchase, with the delivery, when the buyer gave an address. It sends subscribers no renewal reminders, so any reminder has to come from your own tool.

Fianto notices an ended shop subscription on a check that runs every 30 seconds and looks back seven days, and sends subscription.ended once per purchase.

What happens when Zapier or Make does not answer

Shop events use the same delivery machinery as Fianto's developer webhooks. An answer of 2xx within 10 seconds counts as delivered; anything else is retried, up to 8 attempts over about 28 hours. Delivery is at least once, so a Zap can see the same event twice: filter on id or order_id if a duplicate would hurt, such as a second invitation.

After 5 events in a row run out of retries, the connection shows as Paused: "Paused: your app stopped accepting events. Check it, then replace the URL to start again." Events are held meanwhile, and saving the URL again sends what was held. Two things commonly cause it. A Zap that was turned off answers with an error. And Make's webhook documentation says a webhook left unconnected to any scenario for more than 5 days is deactivated and answers 410 Gone. The same page states that "Make can process up to 300 incoming webhook requests per 10 second interval," far above what a shop sends.

Disconnect stops the sending and deletes every event kept for that hook, since they carry buyers' emails. Delivered events are pruned after a week anyway. The dashboard's own words: "Fianto stops sending purchases to it. Buyers who already have access keep it."

When to use developer webhooks instead

Use developer webhooks when the two-event feed is too coarse. Shop sales run on their own application, named Shop and listed under Developers, whose webhook endpoint receives the full event set: subscription.renewed, subscription.past_due, subscription.cancel_scheduled and the rest. A shop sale's checkout session carries metadata.source set to "shop". Payment link sales arrive there too, with metadata.source set to "payment_link". Those deliveries need a server that verifies Standard Webhooks signatures, and their amounts are base units.

A rule of thumb: if losing access on a failed renewal within the day matters to you, or you sell through payment links, write the small server. If a one-off sale or a membership that opens on purchase and closes at the end is enough, Zapier or Make will do. A paid Discord role needs the small server too, because the shop feed carries no Discord ID: see paid Discord roles with USDC. Webhooks for access maps each developer event to an access decision, and the docs page Shop sales in your integration covers the Shop application.