Pulse Direct integration

One session ID. One verified event.

Pulse itself does not require an advertiser SDK. Your stack only needs to preserve the pseudonymous Pulse session identifier and send one authenticated server-side callback after the agreed milestone is confirmed.

Plan a pilot Business overview

No Pulse user ID shared Server-side settlement Idempotent callbacks

01No advertiser SDKPreserve one pseudonymous session ID.

02One server eventConfirm the milestone your product already trusts.

03Settlement after proofBudget and user reward move only after verification.

01 · Protected start

Preserve the session identifier.

When a user starts an eligible direct Drop, Pulse reserves campaign capacity before redirecting them. The destination receives only the campaign and pseudonymous session identifiers.

https://your-product.example/start
  ?pulse_session_id=<uuid>
  &pulse_campaign_id=<uuid>

Privacy boundaryThe redirect does not append the user's Pulse account ID, email or balance identity.

02 · Your event

Confirm the milestone you actually value.

Examples include tutorial completion, first multiplayer match, qualified registration, trial activation or another objective event agreed before campaign launch.

App backend

Server event

Your backend stores the Pulse session ID with the acquired user/session and calls Pulse when the milestone becomes authoritative.

MMP / attribution

Postback path

If your attribution stack can preserve a click parameter and return it with the conversion event, use the Pulse session ID as that correlation value.

Web product

Server conversion

Carry the Pulse session through your own session/order/signup flow, then notify Pulse after your server confirms the target result.

03 · Callback

Send one authenticated completion.

The campaign callback secret remains server-side. Repeating the same confirmed event is idempotent and cannot credit the user twice.

POST /api/direct/callback
Authorization: Bearer <campaign-callback-secret>
Content-Type: application/json

{
  "campaignId": "<pulse-campaign-id>",
  "sessionId": "<pulse-session-id>",
  "externalEventId": "your-unique-event-id",
  "occurredAt": "2026-09-12T20:00:00Z",
  "metadata": {
    "event": "tutorial_completed"
  }
}

04 · Settlement

Settle only after the event is verified.

1ValidateCampaign, secret, session, expiry and event identity

→

2ConsumeReserved budget becomes verified spend

→

3CreditUser reward enters the verified account balance

What Pulse does not require

Keep the first pilot small.

No public advertiser dashboard required No client-side reward claim No arbitrary JavaScript conversion pixel No access to Pulse financial tables No open-ended campaign spend No integration before pilot economics are approved

Technical fit first

Tell us the event. We'll tell you if the pilot is practical.

A campaign request does not create spend or funding authority. We review the verification path before asking for budget.

Request pilot review