Connect Pipedrive
to iMessage.

From a qualified deal to an iMessage reply and a follow-up activity.

This is a custom integration blueprint using the Pipedrive API and Miss Blue API. It is not a one-click Pipedrive Marketplace installation. You need a server or automation worker with durable storage, credentials for both accounts, an authorized Miss Blue number, and permission to contact the selected person.

1. 1. Choose one stage transition

   For example, enroll a deal when it moves into your “Demo requested” stage, has a linked Person with a verified destination, and has recorded permission for this follow-up. Use your actual numeric stage ID. A webhook about any deal edit is only a candidate: reload the current deal and person, check the prior transition, and skip unchanged or already enrolled records.

   Subscribe to the relevant Pipedrive webhook events using its current Webhooks API. Version 2 envelopes contain a unique event ID in meta.id and changed prior fields in previous. Authenticate the delivery using Pipedrive’s supported configuration; do not apply Miss Blue’s signature format to a different provider.

2. 2. Record the decision before sending

   In your database, atomically save the accepted event and a pending workflow action. Use a unique enrollment key such as company + deal + workflow version, and record which owner maps to which granted Miss Blue number. Check your suppression state again immediately before dispatch. A contact who opts out while work is queued must not receive the queued follow-up.

   Start with the sandbox. Its virtual number simulates delivery and replies without contacting a person. Switch to a live number only for your controlled live trial.

3. 3. Send a specific, expected message

   An example message for an opted-in demo request: “Hi Jordan, this is Alex at Example Co. You asked about a demo—would Tuesday afternoon work?” The server posts the selected number_id, recipient, and text to /v1/messages. Store the returned message ID. A 201 response means the send was accepted; it does not prove delivery or a customer reply.

   Keep deduplication in your adapter and follow the API’s documented retry contract. Do not invent an Idempotency-Key header and assume it works. If a request times out with an unknown outcome, reconcile provider state or surface it for review rather than automatically sending a new message.

4. 4. Turn a reply into one assigned activity

   Subscribe to a signed Miss Blue project webhook for message.received. Verify the raw request, deduplicate the envelope id, and map data.number.id plus data.message.sender_handle to your stored Person and Deal. Use the known thread mapping if the sender address is absent; otherwise queue it for review. Never infer the Person from data.message.from (an opaque id on an iMessage line) or a display name.

   Create an unfinished Pipedrive activity for the current deal owner, linked to the Deal and Person. The current Activities API uses participants to set the primary Person. The sample below is a request-body example for POST /api/v2/activities; replace the fixture IDs with your stored mapping and use an activity type configured in your account.

   {
     "subject": "Reply to Jordan’s demo question",
     "type": "task",
     "owner_id": 123,
     "deal_id": 456,
     "participants": [{ "person_id": 789, "primary": true }],
     "done": false,
     "note": "Customer replied on the business line. Open the mapped Miss Blue conversation."
   }

   Persist the returned activity ID. If the CRM request has an ambiguous outcome, reconcile before retrying the creation. Avoid putting private message content into diagnostic logs or unnecessarily duplicating the whole transcript in the CRM.

5. 5. Hand the conversation to its owner

   Move your adapter’s workflow into a human-owned state and stop pending automated replies before notifying the rep. The rep continues the conversation in Miss Blue’s Message Center. A personal pin helps that member find the thread; it does not pause an external automation or assign the CRM deal. Implement those ownership changes explicitly.

6. 6. Run the failure cases before rollout

   Replay the same stage event twice, send two unrelated edits while the deal stays in the stage, change the owner before the reply arrives, remove the phone number, block the contact, and temporarily fail the CRM write. Expected result: one enrollment, no send to an excluded lead, and one recoverable follow-up task for a valid reply.