Authentication & Authorization

ResultFly uses two different authentication modes because CDP ingest and campaign runtime are different surfaces.

1. Authentication Modes

Server-to-server API keys for CDP ingest and administrative operations.
User-context JWTs for runtime APIs that act on behalf of a specific participant.

Use the right mode for the right job:

backend systems sending customer events should use API keys
web or mobile clients running campaign flows should use JWT-based user context

2. CDP API Keys

CDP API keys are intended for secure backend use only.

Typical use cases:

sending customer events into ResultFly
operating server-side ingest integrations
calling protected administrative APIs for CDP-related workflows

Usage:


Authorization: Bearer <api_key>

Operational rules:

issue keys per integration, not per engineer
rotate keys regularly
revoke keys that are no longer needed
never ship ingest keys into browser or mobile code

3. User Tokens for Runtime

JWTs represent an authenticated participant during campaign execution.

They are used for runtime endpoints such as variable reads or writes, not for canonical CDP ingest.

Minimum expectations:

iss identifies the trusted issuer
aud targets the ResultFly runtime audience
exp defines expiry
sub identifies the authenticated participant

Additional claims may carry identity context according to the campaign’s authentication setup.

4. Authorization Boundaries

Authentication proves who is calling. Authorization defines what that caller may do.

ResultFly applies different boundaries:

API keys are scoped to allowed backend operations
JWT-based runtime calls are scoped to the authenticated user context
cross-user access is blocked in runtime APIs
calls outside the granted scope return 403 Forbidden

5. Example: CDP Ingest with API Key


curl -X POST https://api.resultfly.com/v1/cdp/events \
  -H "Authorization: Bearer rf_live_sk_example" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "brand.pos",
    "externalEventId": "txn_987654321",
    "eventType": "purchase_completed",
    "occurredAt": "2026-05-20T12:45:00Z",
    "identity": {
      "externalUserId": "L-123456789",
      "email": "customer@example.com"
    },
    "properties": {
      "amount": 120.50,
      "currency": "USD",
      "store_id": "store_42"
    }
  }'

6. Example: Runtime Mutation with JWT

The exact runtime route depends on the deployed runtime surface. Authentication stays the same:


curl -X POST https://api.resultfly.com/<runtime-endpoint> \
  -H "Authorization: Bearer eyJhbGciOi...example.jwt" \
  -H "Content-Type: application/json" \
  -d '{
    "campaignId": "cmp_abc123",
    "ops": [
      {
        "path": "state.user_campaign.tasks_completed",
        "op": "inc",
        "value": 1
      }
    ],
    "mutationId": "mut_001"
  }'