Test a Drip integration

Prove one empty process, one callback receiver, and one approved contact end to end.

Prompt your AI agent

Recommended

Use the `dino-pong` skill to test one Drip and its callback receiver.
Verify the workspace, owner, agent, infrastructure, and receiver first.
Ask me to choose every process timing, VAD, Lens, and capacity value.
Create only an empty process after approval.
Show the exact destination and payload before one separate call approval.
Correlate the contact, call, callback, and failed-delivery evidence.

Use the Dino CLI directly

dino workspace current
dino workspace check
dino account get
dino process create-drip --help
dino process place-call --help

Assumption

Your agent has already been successfully deployed to Base. Keep its Base agent ID available for the next step.

Step 1: list available Drip infrastructure

Run these commands from your configured Dino workspace:

dino catalog vox-servers

dino catalog transport-dids \
  --direction outbound

dino catalog partner-credentials

Save the selected:

region
Dino server ID
outbound transport DID ID
partner credential ID

These commands only read the infrastructure available to your account. They do not create a campaign or place a call.

Step 2: create an empty Drip

dino process create-drip \
  --agent-id <AGENT_GENESIS_ID> \
  --name <DRIP_NAME> \
  --region <REGION> \
  --vox-server-id <DINO_RUNTIME_ID> \
  --transport-did-id <OUTBOUND_DID_ID> \
  --partner-credentials-id <PARTNER_CREDENTIAL_ID> \
  --vad-mode <VAD_MODE> \
  --hard-close-secs <90-900> \
  --lens-ttl-days <30-180> \
  --process-limit <1-255> \
  --confirm-mutation process.drip.create

Choose each setting before approval. Confirm that process-limit fits the selected DID's available on-demand capacity. Idle prompts and timing come from the agent flow (lifecycleAudio.idle), not this command; without that configuration they are disabled.

Use the agent genesis by default. Each new call then resolves the latest active version in that lineage. Supply an exact version ID only when the process must remain pinned to that version.

What the callback secret is for

Pulse uses this Drip-specific secret to sign the terminal callback it sends to each contact's callback_url. Store the secret in your callback receiver. The receiver uses it to verify X-Dinodial-Pulse-Signature before accepting the result. Pulse also sends X-Dinodial-Pulse-Process-Id so a shared receiver can select the correct Drip secret before verification.

The callback secret is not used to create contacts or authenticate requests to Pulse; your Pulse account API key does that. It is also separate from any HMAC secret used by an agent integration plugin.

Pulse returns callbackSecret only when the Drip is created. Store it immediately in your approved secret manager and never expose it in source control, logs, screenshots, or support messages.

Save the returned process id as the Drip ID. Creating an empty Drip does not place a call.

Confirm that it is running and empty:

dino process get \
  --process-id <DRIP_ID>

Step 3: deploy your callback receiver

Use receiver code that your organization controls. Public documentation does not distribute a callback receiver source package. The installed dino-pong skill supplies Drip operations and recovery guidance, not receiver source.

Before deployment, run the implementation's formatting, test, static-analysis, and production-build checks.

Configure the receiver in this order:

1. Deploy one HTTPS POST endpoint in infrastructure assigned to your account.
2. Store callbackSecret in an approved secret manager.
3. Map X-Dinodial-Pulse-Process-Id to the process-specific secret binding.
4. Verify the signature against the unmodified request body.
5. Require the signed body and header to contain the same process ID.
6. Persist each accepted outcome by dd_pulse_id before returning 2xx.
7. Enable the process mapping only after the secret is available.

Before each deployment mutation, verify the command directory, active account, exact service, data store, and expected effect. Obtain explicit approval for that mutation.

Verify the deployed callback URL:

curl -i \
  -X POST \
  -H 'Content-Type: application/json' \
  --data '{}' \
  <CALLBACK_HTTPS_URL>

The unsigned request must return 401 and must not create a durable record. See Receive Drip outcome callbacks for the complete receiver and recovery procedure.

Step 4: place one direct test call

Real call

This command creates a real, potentially billable call. Review the destination and exact payload immediately before running it.

unique_id is the correlation ID you choose for one contact inside this Drip. Use the source system's lead ID or another stable value, and never reuse it for a second contact in the same process. Pulse returns its own generated dd_pulse_id separately.

dino process place-call \
  --process-id <DRIP_ID> \
  --unique-id <NEW_PROCESS_SCOPED_UNIQUE_ID> \
  --phone <APPROVED_E164_NUMBER> \
  --callback-url <CALLBACK_HTTPS_URL> \
  --placeholders <PLACEHOLDERS_JSON_PATH> \
  --confirm-mutation process.drip.placeCall

Add --plugin-contexts <PLUGIN_CONTEXTS_JSON_PATH> only when the agent uses integration context. Save the returned dd_pulse_id.

Verify the terminal result:

dino process get --process-id <DRIP_ID>
dino process list-calls --process-id <DRIP_ID>
dino process failed-callbacks --process-id <DRIP_ID>

The test passes when your receiver stores the matching signed callback and the failed-callback queue is empty.

Next step

Set up and test the customer-specific ingress Worker without submitting another contact.