Book a demo
databeginner8 min setupby Mantle

New Stripe customer to an Airtable record

Every customer Stripe creates is written into an Airtable base so non-engineers can work the list.

Request this template in a demoTalk to sales
Customer createdCreate the recor

Drag to pan, pinch to zoom. This is the real graph the template installs.

Purpose

Every customer Stripe creates is written into an Airtable base so non-engineers can work the list.

How it works

What it does

  • Listens for Stripe's customer.created.
  • Creates one Airtable record per customer with the Stripe id, e-mail and name.

Validation

This template is contract-validated: the unit suite checks every node type, every config key and the whole graph against the same rules a saved workflow passes. It has not been run against the live provider — the ids, names and columns below are placeholders to replace with your own.

Nodes 2

  1. 01Customer createdtrigger.stripe_eventTrigger
  2. 02Create the recordairtable.create_recordApp
View template JSON
{
  "format": "mantle-workflow/v1",
  "id": "stripe-new-customer-to-airtable",
  "name": "New Stripe customer to an Airtable record",
  "graph": {
    "nodes": [
      {
        "id": "event",
        "type": "trigger.stripe_event",
        "label": "Customer created",
        "config": {
          "events": [
            "customer.created"
          ]
        },
        "worker_type": "generic-worker",
        "position": {
          "x": 60,
          "y": 220
        }
      },
      {
        "id": "record",
        "type": "airtable.create_record",
        "label": "Create the record",
        "config": {
          "base_id": "appXXXXXXXXXXXXXX",
          "table": "Customers",
          "fields": {
            "Stripe ID": "{{ $json.object_id }}",
            "Email": "{{ $json.data_object.email }}",
            "Name": "{{ $json.data_object.name }}",
            "Created": "{{ $now }}"
          }
        },
        "worker_type": "generic-worker",
        "position": {
          "x": 380,
          "y": 220
        }
      }
    ],
    "edges": [
      {
        "from": "event",
        "to": "record"
      }
    ]
  }
}

Requirements

The connections and permissions each step needs, from the node contracts in the catalog.

  • StripeAPI key

    Used by Customer created.

    Credential: the Stripe secret key (sk_…)

    • The key needs write access to webhook endpoints — a restricted key without it can read charges and still fail to publish. Publishing also needs MANTLE_APP_PUBLIC_BASE_URL set to an https URL Stripe can reach; Stripe refuses a livemode endpoint that is not https.
    • Publishing creates the endpoint in Stripe; unpublishing, disabling or archiving deletes it. A workflow that is off is off at Stripe too.
    • Each delivery is verified against Stripe's signature over '{timestamp}.{body}' and refused outside a 5-minute window.
    • Test-mode and live-mode keys are separate accounts at Stripe: a test key registers an endpoint that only ever receives livemode=false events.
    • Stripe allows 16 webhook endpoints per account and this trigger creates one per published workflow, so a 17th publish is refused with Stripe's own message.
  • AirtableBearer token

    Used by Create the record.

    Credential: the Airtable access token

Setup

  • base_id starts app… and is in the base's URL; table is the table name or id.
  • The fields keys are your Airtable column names — Airtable refuses a field it does not have.
  • Pick Stripe and Airtable connections.

Sample input and output

Synthetic examples: node-contract samples or placeholders, never customer data.

Input

What the Customer created trigger receives, as its node contract samples it.

{
  "api_version": "2024-06-20",
  "created": 1717070400,
  "created_at": "2024-05-30T12:00:00Z",
  "data_object": {
    "amount": 4200,
    "currency": "usd",
    "customer": "cus_QAbC1dEfGh2Ijk",
    "id": "pi_3Ox2mB2eZvKYlo2C1kQ8sJ4d",
    "object": "payment_intent",
    "receipt_email": "buyer@example.com",
    "status": "succeeded"
  },
  "id": "evt_1Ox2mB2eZvKYlo2CvQ0Tn9aE",
  "livemode": false,
  "object_id": "pi_3Ox2mB2eZvKYlo2C1kQ8sJ4d",
  "object_type": "payment_intent",
  "payload": {
    "id": "evt_1Ox2mB2eZvKYlo2CvQ0Tn9aE",
    "object": "event"
  },
  "previous_attributes": {},
  "request_id": "req_9Kc0Qm3sT1uW2x",
  "type": "payment_intent.succeeded"
}

Output

Create the record airtable.create_record

{
  "ok": false,
  "record_id": ""
}

Failure handling

What the graph does when a step fails, read from its retry settings, error branches and error policies.

  • A step that fails, after any retries, fails the run. The failed step is kept with its input and error.

See it run, then make it yours.

Templates install as drafts. Edit any step, and Workflow Health re-checks the graph on every save.

Book a technical demoTalk to sales