Migrate from v1 to v2!

With /v1 endpoints being retired on May 31, 2026 we wanted to post a guide on what you would need to change with your v1 integrations.



PulsePoint DSP API — v1 to v2 Migration Guide

Effective May 31, 2026 — v1 endpoints will be retired

Overview

This guide covers everything you need to migrate your integration from the v1 API to v2. The v1 endpoints will be retired on May 31, 2026. All new endpoints released after that date will be available on v2 only.

The key changes in v2 are:

  • New URL structure — all endpoints now include the account ID in the path.
  • HTTP method changes — updates use PATCH instead of PUT for partial updates.
  • Standardized error responses across every endpoint.
  • A request_id on every response for easier troubleshooting.
  • New endpoints not available in v1.

1. Base URL & Path Structure

All rewritten v2 endpoints follow a consistent path structure that includes the account ID:

v1:  `https://lifeapi.pulsepoint.com/RestApi/v1/{resource}/{id}`
v2:  `https://lifeapi.pulsepoint.com/RestApi/v2/account/{accountId}/{resource}/{id}`

Note: Metadata and lookup endpoints that sit outside the account hierarchy (e.g., advertiser lookups) may not follow this pattern — refer to the v2 API reference for those endpoints. In addition, if you are using the /campaignImport/ endpoints, those also do not follow this pattern.

2. Endpoint Changes

The table below maps every v1 endpoint to its v2 equivalent. Note that update operations have moved from PUT (full replace) to PATCH (partial update). If you need full-replace behavior, use the explicit Replace endpoints in v2.

Endpointv1v2
Update CampaignPUT /v1/campaign/{id}PATCH /v2/account/{account_id}/campaigns/{campaign_id}
Get CampaignGET /v1/campaign/{id}GET /v2/account/{account_id}/campaigns/{campaign_id}
Get Line ItemGET /v1/lineitem/{id}GET /v2/account/{accountId}/lineitems/{lineItem_id}
Replace Line ItemPUT /v1/lineitem/{id}PUT /v2/account/{accountId}/lineitems/{lineItem_id}
Update Line ItemPATCH /v2/account/{accountId}/lineitems/{lineItem_id}
Get TacticGET /v1/tactic/{id}GET /v2/account/{accountId}/tactics/{tactic_id}
Update TacticPUT /v1/tactic/idPATCH /v2/account/{accountId}/{tactics}/{tactic_id}
Get CreativeGET /v1/lifecreative/{creativeId}GET /v2/lifecreative/{creativeId}
Create CreativePOST /v1/lifecreative/account/{accountId}POST /v2/lifecreative/account/{accountId}
Update CreativePUT /v1/lifecreative/{creativeId}PUT /v2/lifecreative/{creativeId}
Assign CreativesPUT /v1/lifecreative/account/{accountId}/creativeassociationPUT /v2/lifecreative/account/{accountId}/creativeassociation
Get NPI ListGET /v1/npi/npi-list/{list_id}GET /v2/npi/npi-list/{list_id}
Add NPIsPATCH /v1/npi/npi-list/{list_id}PATCH /v2/npi/npi-list/{list_id}
Replace NPIsPUT /v1/npi/npi-list/{list_id}PUT /v2/npi/npi-list/{list_id}
Create NPI ListPOST /v1/npi/npi-list/account/{accountId}POST /v2/npi/npi-list/account/{accountId}
GET NPI With AttributesGET /v1/npi/npi-list/{id}/attributesGET /v2/npi/npi-list/{id}/attributes
Replace NPI List With AttributesPUT /v1/npi/npi-list/{id}/attributesPUT /v2/npi/npi-list/{id}/attributes
Update NPI List With AttributesPATCH /v2/npi/npi-list/{id}/attributes
Get NPI Lists by AccountGET /v1/npi/npi-list/account/{accountId}GET /v2/npi/npi-list/account/{accountId}
Create NPI List With AttributesPOST /v1/npi/npi-list/account/{accountId}/attributesPOST /v2/npi/npi-list/account/{accountId}/attributes
GET NPI list meta dataGET /v1/npi/npi-list/{list_id}/liteGET /v2/npi/npi-list/{id}/lite
GET Medscape NPI ListGET /v1/npi/npi-list/{id}/medscapeNPIGET /v2/npi/npi-list/{id}/medscapeNPI

4. Field Changes

Dayparting (Line Item & Tactic)

The dayparting field within the flight object has been restructured in v2. If your integration reads or writes dayparting schedules on line items/tactics, you will need to update that portion of your payload. Refer to the v2 Update Line Item reference for the updated schema.

5. Error Response Format

In v1, error responses were inconsistent — some endpoints returned empty bodies, others used varying schemas. In v2, all endpoints return a standardized error envelope.


FieldTypeDescription
successbooleanAlways false for error responses.
error.codestringMachine-readable error type. Use this for programmatic handling — it is stable across releases
error.messagestringHuman-readable summary of the error. Safe to display to end users
error.detailsarrayOptional array of field-level validation issues, each with field, message, code, value, and expected.
timestampstringISO-8601 timestamp of when the error occurred.
pathstringThe endpoint path that was called.
request_idstringUnique ID for this request. Include this when contacting PulsePoint support.
{
  "success": false,
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Line item validation failed",
    "details": [
      {
        "field": "name",
        "message": "Line item name is required",
        "code": "REQUIRED_FIELD"
      }
    ]
  },
  "timestamp": "2025-10-08T14:30:00.000Z",
  "path": "/v2/account/12345/lineitems",
  "request_id": "req_abc123"
}

Error Codes

Use the error.code field — not the message — for programmatic error handling, as codes are stable across releases. Key codes to handle can be found here.


6. Authentication

Authentication is unchanged between v1 and v2. Continue using the same OAuth2 bearer token flow: POST https://lifeapi.pulsepoint.com/RestApi/oauth/token

7. Migration Checklist

  1. Update all endpoint paths to include /v2/account/accountId/ in the URL where applicable.
  2. Change PUT calls for Update Campaign, Update Line Item, and Update Tactic to PATCH where applicable.
  3. Update error handling code to parse the new standardized error envelope — use error.code for logic, error.message for display.
  4. Log the request_id from every response — include it in any support requests.
  5. If your integration reads or writes dayparting within flight objects, update to the v2 schema.
  6. Test against all endpoints you use before the May 31, 2026 cutoff.