Skip to main content
v2 is the current, stable API; v1 is legacy and deprecated. The two surfaces differ in shape, not in access: v1 is a verb/RPC-style API with ad-hoc responses, while v2 is RESTful with a consistent envelope, cursor pagination, and structured errors. This page maps the old paths to the new ones and lists what changes in your code.
Your authentication doesn’t change. Both surfaces use the same Authorization: Bearer YOUR_API_KEY header — keep your existing key. See Authentication.

​
What changes at a high level

  • RESTful resources replace verb paths. Actions like add-creator and creator/delete become standard methods on resources (POST /v2/creators, DELETE /v2/creators/{id}).
  • A consistent response envelope. v2 wraps every response in { data } or { data, pagination }; v1 returned ad-hoc shapes. Update your parsers to read data.
  • Cursor pagination. v2 list endpoints page with limit + cursor and return a pagination block. Adopt the pagination loop.
  • RFC 9457 errors. v2 returns application/problem+json with a machine-readable code. Branch your error handling on status + code — see Errors.
  • Unified videos. v1 had separate Instagram-post and TikTok-video endpoints. v2 has a single /videos resource with a platform field.

​
Path mapping

The tables below map each legacy v1 path to its v2 method and path. Where a v1 verb toggled state (activate/deactivate), the v2 equivalent is a PATCH that sets is_active.

​
Creators

v1 pathv2 method + path
POST /v1/add-creatorPOST /v2/creators
GET /v1/list-creatorsGET /v2/creators
GET /v1/creatorGET /v2/creators/{id}
POST /v1/creator/modifyPATCH /v2/creators/{id}
DELETE /v1/creator/deleteDELETE /v2/creators/{id}
POST /v1/creator/activatePATCH /v2/creators/{id} (set is_active)
POST /v1/creator/de-activatePATCH /v2/creators/{id} (set is_active)
POST /v1/creator/add-accountPUT /v2/creators/{id}/accounts/{account_id}
POST /v1/creator/remove-accountDELETE /v2/creators/{id}/accounts/{account_id}

​
Accounts

v1 pathv2 method + path
POST /v1/add-account, POST /v1/account/start-trackingPOST /v2/accounts
GET /v1/list-accountsGET /v2/accounts
GET /v1/accountGET /v2/accounts/{id}
POST /v1/account/modifyPATCH /v2/accounts/{id}
POST /v1/account/stop-trackingDELETE /v2/accounts/{id} (or PATCH is_active=false)
DELETE /v1/account/deleteDELETE /v2/accounts/{id} (or PATCH is_active=false)
GET /v1/account/videoGET /v2/accounts/{id}/videos

​
Videos

v2 unifies the platform-specific endpoints into one /videos resource. Pass platform (and an identifier) on create, and filter by platform=… on list.
v1 pathv2 method + path
POST /v1/add-instagram-post, POST /v1/add-tiktok-videoPOST /v2/videos (platform + identifier)
GET /v1/list-instagram-posts, GET /v1/list-tiktok-videosGET /v2/videos (filter platform=…)
GET /v1/instagram-post/{id}, GET /v1/tiktok-videoGET /v2/videos/{id}
*/modifyPATCH /v2/videos/{id}
*/activate, */deactivatePATCH /v2/videos/{id} (set is_active)
DELETE (per platform)DELETE /v2/videos/{id}
GET /v1/video-deltasGET /v2/videos/deltas

​
Analytics & system

v1 pathv2 method + path
GET /v1/daily-analyticsGET /v2/analytics/timeseries, GET /v2/{resource}/{id}/analytics
GET /v1/overview-statsGET /v2/overview
GET /v1/healthGET /v2/health

​
What else changes in your code

Beyond swapping paths, three conventions change across the board:
  • Envelope parsing. Read results from data (single resource) or data plus pagination (collections) instead of the ad-hoc v1 shapes.
  • Pagination loop. For list endpoints, request a limit, then follow pagination.next_cursor while pagination.has_next is true. See Pagination.
  • Error handling. Catch application/problem+json responses and branch on the numeric status plus the machine-readable code. See Errors.

​
Next steps

Start from the Introduction for the full v2 envelope and conventions, then review Pagination, Errors, and Versioning before you cut over.