Overview

If your integration was built against the original Rise V1 API, you do not need to rewrite it to keep working. Every V1 endpoint your code already calls is still live, at the exact same path, with the exact same request and response shape. Once your account finishes migrating to Rise’s new infrastructure, these endpoints are served directly by the new platform instead of the old V1 backend — your integration doesn’t need to notice the difference.

In a hurry? Jump to the Quickstart

A copy-paste-runnable script that authenticates, lists your teams, and sends a payment — start there if you just want working code.

This section documents the V1 Legacy endpoints as a reference for existing integrations. If you’re starting a new integration, use the B2B API instead — see the Migration Guide for the V1 → B2B endpoint mapping.

How it works

Before migration

Requests to /v1/* are transparently forwarded to the original V1 backend. Behavior is identical to calling V1 directly.

After migration

The same /v1/* requests are served by Rise’s new infrastructure. Paths, request fields, and response fields stay the same.

Your integration

No code changes required for either phase — the same request produces the same response shape throughout.

Base URLs

Environment	Base URL
Production	`https://b2b-api.riseworks.io`
Staging	`https://b2b-api.staging-riseworks.io`

Response format

These endpoints keep V1’s original response envelope — not the B2B API’s { success, data } wrapper:

{
  "data": { }
}

Errors from request validation use V1’s original shape:

{
  "error": "Bad Request",
  "message": {
    "type": "invalid_parameters",
    "errors": {
      "wallet": ["Missing parameter wallet"]
    }
  }
}

Other errors (not found, forbidden, etc.) return:

{
  "error": "Not Found",
  "message": "Team not found"
}

One case breaks this pattern: when a company/team isn’t enabled for B2B API access, GET /v1/teams and the impersonation flow on POST /v1/auth/api/siwe return 403 in the B2B API’s envelope instead — { "success": false, "data": "Company is not enabled for B2B API access", "error_code": "B2B_ACCESS_DENIED" }. If your error handling only checks for the error/message shape above, add a check for error_code too.

Identifier formats

Outside of authentication, every team/company/user identifier param here (rise_id, payee, teamId, talentId, company_id, company_riseid, payee_riseid, payee_ids, etc.) accepts any of the following interchangeably:

Format	Example
V1 RiseID (address)	`0xabc...`
V2 RiseID (address)	`0xdef...`
Nanoid	`te-abc123def456`, `us-xyz789abc123`, `co-...`
RiseAccount address	`0x123...` (the entity’s on-chain smart account, distinct from its RiseID)
Legacy numeric V1 id	`12345` (team/company endpoints only)

The server resolves whichever format you send to the same underlying entity — pick whatever your integration already has on hand, no conversion needed on your end.

This is different from Authentication’s rise_id, which must specifically be a team/company RiseID (not a nanoid or RiseAccount address), since it’s parsed out of a signed SIWE message rather than resolved server-side.

Authentication

All endpoints except the SIWE endpoints themselves require a bearer JWT, obtained via POST /v1/auth/api/siwe — see Authentication.

Authorization: Bearer <jwt>

Using the SDK

The riseworks-sdk client exposes every endpoint here under client.v1Legacy, alongside the same client.teams, client.payments, etc. namespaces used for the B2B API:

npm install riseworks-sdk

const { RiseApiClient } = require('riseworks-sdk');

const client = new RiseApiClient({
  environment: 'prod',
  riseIdAuth: {
    riseId: process.env.RISE_ID,
    privateKey: process.env.PRIVATE_KEY,
  },
});

// Endpoints from this section
const teams = await client.v1Legacy.listTeams();

// B2B endpoints — same client, same JWT
const balance = await client.entityBalance.get({ nanoid: process.env.RISE_ID });

See each endpoint page for the full client.v1Legacy.* method list — getSiwe/verifySiwe, pay/preparePay/executePay, batchPay/prepareBatchPay/executeBatchPay, createBatchPaymentIntents, listPayments, listTeams, listTalent/getTalent/removeTalent, getBalance, listInvites/sendInvites/sendWarmedInvites.

The example above uses riseIdAuth with a personal RiseID. Most API integrations instead authenticate a delegate wallet directly against a team or company RiseID — see Authentication for that flow, since it requires calling getSiwe/verifySiwe manually.

Endpoint groups

Authentication

SIWE message generation and signature verification

Payments

Instant and batch payments, payment intents, and payment history

Teams & Talent

List teams, list/get/remove contractors

RiseID Balance

Query on-chain USD balance for a team, user, or company

Invites

List and send contractor/client invites, including pre-filled (warmed) invites

Troubleshooting

Common errors across every endpoint, and how to fix them

These endpoints are supported for existing integrations only and will eventually be deprecated. Plan to move to the B2B API when convenient — there’s no urgency, but new work should target B2B directly.

Getting Started

Endpoints

Help

In a hurry? Jump to the Quickstart

How it works

Base URLs

Response format

Identifier formats

Authentication

Using the SDK

Endpoint groups

Authentication

Payments

Teams & Talent

RiseID Balance

Invites

Troubleshooting

In a hurry? Jump to the Quickstart

​How it works

​Base URLs

​Response format

​Identifier formats

​Authentication

​Using the SDK

​Endpoint groups

Authentication

Payments

Teams & Talent

RiseID Balance

Invites

Troubleshooting

How it works

Base URLs

Response format

Identifier formats

Authentication

Using the SDK

Endpoint groups