Create User with Clerk API on New Contact from Twilio SendGrid API

Pipedream makes it easy to connect APIs for Clerk, Twilio SendGrid and 2,400+ other apps remarkably fast.

Trigger workflow on

New Contact from the Twilio SendGrid API

Next, do this

Create User with the Clerk API

No credit card required

▶

Watch us build a workflow

8 min

Watch now ➜

Trusted by 1,000,000+ developers from startups to Fortune 500 companies

Developers ♥ Pipedream

Getting Started#

This integration creates a workflow with a Twilio SendGrid trigger and Clerk action. When you configure and deploy the workflow, it will run on Pipedream's servers 24x7 for free.

Select this integration
Configure the New Contact trigger
1. Connect your Twilio SendGrid account
2. Configure timer
Configure the Create User action
1. Connect your Clerk account
2. Optional- Configure External Id
3. Optional- Configure First Name
4. Optional- Configure Last Name
5. Configure Email Addresses
6. Optional- Configure Phone Numbers
7. Optional- Configure Web3 Wallets
8. Optional- Configure Username
9. Configure Password
10. Optional- Configure Password Digest
11. Optional- Configure Password Hasher
12. Optional- Configure Skip Password Checks
13. Optional- Configure Skip Password Requirement
14. Optional- Configure TOTP Secret
15. Optional- Configure Backup Codes
16. Optional- Configure Public Metadata
17. Optional- Configure Private Metadata
18. Optional- Configure Unsafe Metadata
19. Optional- Configure Created At
Deploy the workflow
Send a test event to validate your setup
Turn on the trigger

Details#

This integration uses pre-built, source-available components from Pipedream's GitHub repo. These components are developed by Pipedream and the community, and verified and maintained by Pipedream.

To contribute an update to an existing component or create a new component, create a PR on GitHub. If you're new to Pipedream component development, you can start with quickstarts for trigger span and action development, and then review the component API reference.

Trigger#

New Contact on Twilio SendGrid

Description:Emit new event when a new contact is created

Version:0.0.6

Key:sendgrid-new-contact

View on GitHub

Twilio SendGrid Overview#

The Twilio SendGrid API opens up a world of possibilities for email automation, enabling you to send emails efficiently and track their performance. With this API, you can programmatically create and send personalized email campaigns, manage contacts, and parse inbound emails for data extraction. When you harness the power of Pipedream, you can connect SendGrid to hundreds of other apps to automate workflows, such as triggering email notifications based on specific actions, syncing email stats with your analytics, or handling incoming emails to create tasks or tickets.

Trigger Code#

import orderBy from "lodash/orderBy.js";
import common from "../common/timer-based.mjs";

export default {
  ...common,
  key: "sendgrid-new-contact",
  name: "New Contact",
  description: "Emit new event when a new contact is created",
  version: "0.0.6",
  type: "source",
  dedupe: "unique",
  hooks: {
    async activate() {
      const currentTimestamp = Date.now();
      const state = {
        processedItems: [],
        lowerTimestamp: currentTimestamp,
        upperTimestamp: currentTimestamp,
      };
      this.db.set("state", state);
    },
  },
  methods: {
    ...common.methods,
    _maxDelayTime() {
      // There is no report from SendGrid as to how much time it takes
      // for a contact to be created and appear in search results, so
      // we're using a rough estimate of 30 minutes here.
      return 30 * 60 * 1000;  // 30 minutes, in milliseconds
    },
    _addDelayOffset(timestamp) {
      return timestamp - this._maxDelayTime();
    },
    _cleanupOldProcessedItems(processedItems, currentTimestamp) {
      return processedItems
        .map((item) => ({
          // We just need to keep track of the record ID and
          // its creation date.
          id: item.id,
          created_at: item.created_at,
        }))
        .filter((item) => {
          const { created_at: createdAt } = item;
          const createdAtTimestamp = Date.parse(createdAt);
          const cutoffTimestamp = this._addDelayOffset(currentTimestamp);
          return createdAtTimestamp > cutoffTimestamp;
        });
    },
    _makeSearchQuery(processedItems, lowerTimestamp, upperTimestamp) {
      const idList = processedItems
        .map((item) => item.id)
        .map((id) => `'${id}'`)
        .join(", ")
      || "''";
      const startTimestamp = this._addDelayOffset(lowerTimestamp);
      const startDate = this.toISOString(startTimestamp);
      const endDate = this.toISOString(upperTimestamp);
      return `
        contact_id NOT IN (${idList}) AND
        created_at BETWEEN
          TIMESTAMP '${startDate}' AND
          TIMESTAMP '${endDate}'
      `;
    },
    generateMeta(data) {
      const {
        item,
        eventTimestamp: ts,
      } = data;
      const {
        id,
        email,
      } = item;
      const slugifiedEmail = this.slugifyEmail(email);
      const summary = `New contact: ${slugifiedEmail}`;
      return {
        id,
        summary,
        ts,
      };
    },
    async processEvent(event) {
      // Transform the timer timestamp to milliseconds
      // to be consistent with how Javascript handles timestamps.
      const eventTimestamp = event.timestamp * 1000;

      // Retrieve the current state of the component.
      const {
        processedItems,
        lowerTimestamp,
        upperTimestamp,
      } = this.db.get("state");

      // Search for contacts within a specific timeframe, excluding
      // items that have already been processed.
      const query = this._makeSearchQuery(processedItems, lowerTimestamp, upperTimestamp);
      const {
        result: items,
        contact_count: contactCount,
      } = await this.sendgrid.searchContacts(query);

      // If no contacts have been retrieved via the API,
      // move the time window forward to possibly capture newer contacts.
      if (contactCount === 0) {
        const newState = {
          processedItems: this._cleanupOldProcessedItems(processedItems, lowerTimestamp),
          lowerTimestamp: upperTimestamp,
          upperTimestamp: eventTimestamp,
        };
        this.db.set("state", newState);
        return;
      }

      // We process the searched records from oldest to newest.
      const itemsToProcess = orderBy(items, "created_at");
      itemsToProcess
        .forEach((item) => {
          const meta = this.generateMeta({
            item,
            eventTimestamp,
          });
          this.$emit(item, meta);
        });

      // Use the timestamp of the last processed record as a lower bound for
      // following searches. This bound will be subjected to an offset so in
      // case older records appear in future search results, but have not
      // appeared until now, can be processed. We only adjust it if it means
      // moving forward, not backwards. Otherwise, we might start retrieving
      // older and older records indefinitely (and we're all about *new*
      // records!)
      const newLowerTimestamp = Math.max(
        lowerTimestamp,
        Date.parse(itemsToProcess[0].created_at),
      );

      // If the total contact count is less than 100, it means that during the
      // next iteration the search results count will most likely be less than
      // 50. In that case, if we extend the upper bound of the search time range
      // we might be able to retrieve more records.
      const newUpperTimestamp = contactCount < 100
        ? eventTimestamp
        : upperTimestamp;

      // The list of processed items can grow indefinitely.
      // Since we don't want to keep track of every processed record
      // ever, we need to clean up this list, removing any records
      // that are no longer relevant.
      const newProcessedItems = this._cleanupOldProcessedItems(
        [
          ...processedItems,
          ...itemsToProcess,
        ],
        newLowerTimestamp,
      );

      // Update the state of the component to reflect the computations
      // made above.
      const newState = {
        processedItems: newProcessedItems,
        lowerTimestamp: newLowerTimestamp,
        upperTimestamp: newUpperTimestamp,
      };
      this.db.set("state", newState);
    },
  },
};

Trigger Configuration#

This component may be configured based on the props defined in the component code. Pipedream automatically prompts for input values in the UI and CLI.

Label	Prop	Type	Description
N/A	`db`	`$.service.db`	This component uses `$.service.db` to maintain state between executions.
Twilio SendGrid	`sendgrid`	`app`	This component uses the Twilio SendGrid app.
	`timer`	`$.interface.timer`

Trigger Authentication#

Twilio SendGrid uses API keys for authentication. When you connect your Twilio SendGrid account, Pipedream securely stores the keys so you can easily authenticate to Twilio SendGrid APIs in both code and no-code steps.

About Twilio SendGrid#

Send marketing and transactional email through the Twilio SendGrid platform with the Email API, proprietary mail transfer agent, and infrastructure for scalable delivery.

Action#

Create User on Clerk

Description:Creates a new user. Your user management settings determine how you should setup your user model. [See the documentation](https://clerk.com/docs/reference/backend-api/tag/Users#operation/CreateUser)

Version:0.0.1

Key:clerk-create-user

View on GitHub

Clerk Overview#

The Clerk API lets you manage user authentication and create secure, delightful user experiences in your apps. Within Pipedream's serverless platform, you can harness this API to automate workflows that trigger on user events, sync user data across apps, and maintain robust user management without the heavy lifting of building authentication infrastructure from scratch.

Action Code#

import clerk from "../../clerk.app.mjs";
import {
  parseError, parseObject,
} from "../../common/utils.mjs";

export default {
  key: "clerk-create-user",
  name: "Create User",
  version: "0.0.1",
  description: "Creates a new user. Your user management settings determine how you should setup your user model. [See the documentation](https://clerk.com/docs/reference/backend-api/tag/Users#operation/CreateUser)",
  type: "action",
  props: {
    clerk,
    externalId: {
      propDefinition: [
        clerk,
        "externalId",
      ],
      optional: true,
    },
    firstName: {
      propDefinition: [
        clerk,
        "firstName",
      ],
      optional: true,
    },
    lastName: {
      propDefinition: [
        clerk,
        "lastName",
      ],
      optional: true,
    },
    emailAddress: {
      type: "string[]",
      label: "Email Addresses",
      description: "Email addresses to add to the user. Must be unique across your instance. The first email address will be set as the user's primary email address.",
    },
    phoneNumber: {
      type: "string[]",
      label: "Phone Numbers",
      description: "Phone numbers to add to the user. Must be unique across your instance. The first phone number will be set as user's primary phone number.",
      optional: true,
    },
    web3Wallet: {
      type: "string[]",
      label: "Web3 Wallets",
      description: "Web3 wallets to add to the user. Must be unique across your instance. The first wallet will be set as the user's primary wallet.",
      optional: true,
    },
    username: {
      propDefinition: [
        clerk,
        "username",
      ],
      optional: true,
    },
    password: {
      propDefinition: [
        clerk,
        "password",
      ],
    },
    passwordDigest: {
      type: "string",
      label: "Password Digest",
      description: "In case you already have the password digests and not the passswords, you can use them for the newly created user via this property. The digests should be generated with one of the supported algorithms. The hashing algorithm can be specified using the `Password Hasher` property.",
      optional: true,
    },
    passwordHasher: {
      type: "string",
      label: "Password Hasher",
      description: "The hashing algorithm that was used to generate the password digest. The algorithms that Clerk supports at the moment are `bcrypt`, `bcrypt_sha256_django`, `md5`, `pbkdf2_sha256`, `pbkdf2_sha256_django`, `phpass`, `scrypt_firebase` and 2 `argon2` variants, `argon2i` and `argon2id`. Each of the above expects the incoming digest to be of a particular format. [See the documentarion](https://clerk.com/docs/reference/backend-api/tag/Users#operation/CreateUser!path=password_hasher&t=request) for further information.",
      optional: true,
    },
    skipPasswordChecks: {
      propDefinition: [
        clerk,
        "skipPasswordChecks",
      ],
      optional: true,
    },
    skipPasswordRequirement: {
      type: "boolean",
      label: "Skip Password Requirement",
      description: "When set to `true`, `password` is not required anymore when creating the user and can be omitted. This is useful when you are trying to create a user that doesn't have a password, in an instance that is using passwords. Please note that you cannot use this flag if password is the only way for a user to sign into your instance.",
      optional: true,
    },
    totpSecret: {
      propDefinition: [
        clerk,
        "totpSecret",
      ],
      optional: true,
    },
    backupCodes: {
      propDefinition: [
        clerk,
        "backupCodes",
      ],
      optional: true,
    },
    publicMetadata: {
      propDefinition: [
        clerk,
        "publicMetadata",
      ],
      optional: true,
    },
    privateMetadata: {
      propDefinition: [
        clerk,
        "privateMetadata",
      ],
      optional: true,
    },
    unsafeMetadata: {
      propDefinition: [
        clerk,
        "unsafeMetadata",
      ],
      optional: true,
    },
    createdAt: {
      propDefinition: [
        clerk,
        "createdAt",
      ],
      optional: true,
    },
  },
  async run({ $ }) {
    if (this.passwordDigest) {
      this.password = null;
    }
    try {
      const response = await this.clerk.createUser({
        $,
        data: {
          external_id: this.externalId,
          first_name: this.firstName,
          last_name: this.lastName,
          email_address: parseObject(this.emailAddress),
          phone_number: parseObject(this.phoneNumber),
          web3_wallet: parseObject(this.web3Wallet),
          username: this.username,
          password: this.password,
          password_digest: this.passwordDigest,
          password_hasher: this.passwordHasher,
          skip_password_checks: this.skipPasswordChecks,
          skip_password_requirement: this.skipPasswordRequirement,
          totp_secret: this.totpSecret,
          backup_codes: parseObject(this.backupCodes),
          public_metadata: parseObject(this.publicMetadata),
          private_metadata: parseObject(this.privateMetadata),
          unsafe_metadata: parseObject(this.unsafeMetadata),
          created_at: this.createdAt,
        },
      });

      $.export("$summary", `A new user with Id: ${response.id} was successfully created!`);
      return response;
    } catch (err) {
      return parseError(err);
    }
  },
};

Action Configuration#

This component may be configured based on the props defined in the component code. Pipedream automatically prompts for input values in the UI.

Label	Prop	Type	Description
Clerk	`clerk`	`app`	This component uses the Clerk app.
External Id	`externalId`	`string`	The ID of the user as used in your external systems or your previous authentication solution. Must be unique across your instance.
First Name	`firstName`	`string`	The first name to assign to the user.
Last Name	`lastName`	`string`	The last name to assign to the user.
Email Addresses	`emailAddress`	`string[]`	Email addresses to add to the user. Must be unique across your instance. The first email address will be set as the user's primary email address.
Phone Numbers	`phoneNumber`	`string[]`	Phone numbers to add to the user. Must be unique across your instance. The first phone number will be set as user's primary phone number.
Web3 Wallets	`web3Wallet`	`string[]`	Web3 wallets to add to the user. Must be unique across your instance. The first wallet will be set as the user's primary wallet.
Username	`username`	`string`	The username to give to the user. It must be unique across your instance.
Password	`password`	`string`	The plaintext password to give to the user. Must be at least 8 characters long, and can not be in any list of hacked passwords.
Password Digest	`passwordDigest`	`string`	In case you already have the password digests and not the passswords, you can use them for the newly created user via this property. The digests should be generated with one of the supported algorithms. The hashing algorithm can be specified using the `Password Hasher` property.
Password Hasher	`passwordHasher`	`string`	The hashing algorithm that was used to generate the password digest. The algorithms that Clerk supports at the moment are `bcrypt`, `bcrypt_sha256_django`, `md5`, `pbkdf2_sha256`, `pbkdf2_sha256_django`, `phpass`, `scrypt_firebase` and 2 `argon2` variants, `argon2i` and `argon2id`. Each of the above expects the incoming digest to be of a particular format. See the documentarion for further information.
Skip Password Checks	`skipPasswordChecks`	`boolean`	When set to `true` all password checks are skipped. It is recommended to use this method only when migrating plaintext passwords to Clerk. Upon migration the user base should be prompted to pick stronger password.
Skip Password Requirement	`skipPasswordRequirement`	`boolean`	When set to `true`, `password` is not required anymore when creating the user and can be omitted. This is useful when you are trying to create a user that doesn't have a password, in an instance that is using passwords. Please note that you cannot use this flag if password is the only way for a user to sign into your instance.
TOTP Secret	`totpSecret`	`string`	In case TOTP is configured on the instance, you can provide the secret to enable it on the newly created user without the need to reset it.
Backup Codes	`backupCodes`	`string[]`	If Backup Codes are configured on the instance, you can provide them to enable it on the newly created user without the need to reset them. You must provide the backup codes in plain format or the corresponding bcrypt digest.
Public Metadata	`publicMetadata`	`object`	Metadata saved on the user, that is visible to both your Frontend and Backend APIs.
Private Metadata	`privateMetadata`	`object`	Metadata saved on the user, that is only visible to your Backend API.
Unsafe Metadata	`unsafeMetadata`	`object`	Metadata saved on the user, that can be updated from both the Frontend and Backend APIs. `Note: Since this data can be modified from the frontend, it is not guaranteed to be safe.`
Created At	`createdAt`	`string`	A custom date/time denoting when the user signed up to the application, specified in RFC3339 format (e.g. `2012-10-20T07:15:20.902Z`).