Testing & Sandbox

Overview Outbound Webhooks Inbound Webhooks Status Lifecycle Case Configuration Testing & Sandbox Onboarding Checklist

Test endpoint

Use the /test endpoint to validate your integration before going live. It runs the full pipeline — authentication, payload normalization, case code resolution, status mapping — but writes nothing to the database.

Test endpoint	POST /api/webhooks/partner-status/test?access_token=...
Production endpoint	POST /api/webhooks/partner-status?access_token=...
Authentication	Same access token for both — provided during onboarding
Data safety	Test endpoint is a dry run — no records created, no notifications sent

Testing inbound webhooks

Send a sample payload to the /test endpoint using your access token. The response shows exactly how we'll parse your data — including normalized fields, case resolution, and status mapping — plus any warnings about missing fields.

bash

curl -X POST \
  'https://api.payme.dev/api/webhooks/partner-status/test?access_token=YOUR_ACCESS_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{
    "LeadId": "test-lead-uuid-from-outbound",
    "Status": "RetainerSigned",
    "CaseName": "SM-YourFirm",
    "ExternalLeadId": "your-test-id-001",
    "ContactPhone": "5551234567"
  }'

Successful response:

json

{
  "Status": "test_success",
  "Message": "Dry run — no data was written",
  "partner": { "slug": "your-partner-slug", "partnerId": "..." },
  "normalized_payload": {
    "LeadId": "test-lead-uuid-from-outbound",
    "Status": "RetainerSigned",
    "CaseCode": "SM-YourFirm",
    "ExternalLeadId": "your-test-id-001",
    "ContactPhone": "5551234567",
    ...
  },
  "case_resolution": {
    "mass_tort_id": "380e602d-...",
    "law_firm": "YourFirm",
    "case_code_input": "SM-YourFirm"
  },
  "status_resolution": {
    "raw_status": "RetainerSigned",
    "normalized_status": "signed"
  }
}

Once you're satisfied with the test response, switch to the production endpoint (remove /test from the URL) to start sending real status updates.

Testing outbound webhooks

Provide a test webhook URL during onboarding (your staging endpoint or a service like webhook.site). We'll send a test lead so you can verify your receiver parses the payload correctly.

End-to-end test flow

Receive a test lead

Both

We send a test lead to your webhook endpoint. Verify you receive it, parse the payload correctly, and store the LeadId.

Send a status update

You

POST a status update back to us using the LeadId from step 1. Verify you get a 200 response.

Send 2-3 more transitions

You

Walk the lead through several statuses (e.g. pre_qualified → docs_requested → signed). Verify each returns 200.

Confirm on our side

PayMe

We verify all statuses were recorded correctly, mapped to the right canonical values, and notifications fired.

Common issues

401Authentication failed

Double-check your access token. It goes in the query parameter, not a header.

400Missing LeadId

Ensure your payload includes a LeadId field (or the field your adapter maps to LeadId).

404Lead not found

Use the UUID from our outbound webhook, not your internal ID. If testing with a made-up UUID, 404 is expected.