Test a Drip integration

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 Vox workspace:

vox catalog vox-servers --format json

vox catalog transport-dids \
  --direction outbound \
  --format json

vox catalog partner-credentials --format json

Save the selected:

region
Vox 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

vox process create-drip \
  --agent-id <AGENT_GENESIS_ID> \
  --name <DRIP_NAME> \
  --region <REGION> \
  --vox-server-id <VOX_SERVER_ID> \
  --transport-did-id <OUTBOUND_DID_ID> \
  --partner-credentials-id <PARTNER_CREDENTIAL_ID> \
  --vad-mode vox_vad_lite \
  --hard-close-secs 300 \
  --idle-prompt-secs 10 \
  --idle-response-secs 10 \
  --lens-ttl-days 30 \
  --confirm-mutation process.drip.create \
  --format json

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:

vox process get \
  --process-id <DRIP_ID> \
  --format json

Step 3: deploy your callback receiver

Use Dinodial's Rust Cloudflare Worker receiver:

git clone https://github.com/dinodial/dinodial-drip-callback-receiver.git
cd dinodial-drip-callback-receiver

cargo fmt --check
cargo test
cargo clippy --all-targets -- -D warnings
worker-build --release

The DinoDial internal receiver is not a customer endpoint. Deploy a separate receiver in the infrastructure assigned to your account, unless DinoDial has provided a dedicated callback URL and confirmed that it is bound to your Drip.

Create your Wrangler configuration from wrangler.example.jsonc, then deploy the Worker and bind the Drip secret:

# Build and validate the configured Worker without publishing it.
wrangler deploy --dry-run

# Apply any pending callback-table migrations to your remote D1 database.
wrangler d1 migrations apply <CALLBACK_D1> --remote

# Publish the callback Worker.
wrangler deploy

# Register the Drip and securely install its process-specific callback secret.
./scripts/register-process <DRIP_ID> <CALLBACK_D1> wrangler.jsonc

The script first reserves the process in D1 as disabled, so concurrent or accidental repeat registration fails before replacing a secret. Paste callbackSecret only into Wrangler's hidden prompt. The secret becomes an encrypted, process-specific Worker binding; only after that succeeds does the script enable the process in D1. One receiver can therefore verify callbacks from multiple concurrent Drips without putting their secrets in D1.

Verify the receiver:

curl -fsS https://<CALLBACK_HOST>/health

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

Health must return {"status":"ok"}. The unsigned request must return 401. For a signed callback, the receiver selects the registered process using X-Dinodial-Pulse-Process-Id, verifies the raw body, and requires the signed body's process_id to match the header. 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.

vox process place-call \
  --process-id <DRIP_ID> \
  --unique-id <NEW_PROCESS_SCOPED_UNIQUE_ID> \
  --phone <APPROVED_E164_NUMBER> \
  --callback-url https://<CALLBACK_HOST>/callbacks \
  --placeholders <PLACEHOLDERS_JSON_PATH> \
  --confirm-mutation process.drip.placeCall \
  --format json

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

Verify the terminal result:

vox process get --process-id <DRIP_ID> --format json
vox process list-calls --process-id <DRIP_ID> --format json
vox process failed-callbacks --process-id <DRIP_ID> --format json

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.