> ## Documentation Index
> Fetch the complete documentation index at: https://docs.riseworks.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> How the original Rise V1 API endpoints keep working after migration to the B2B platform

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.

<Card title="In a hurry? Jump to the Quickstart" icon="bolt" href="/v1-legacy/quickstart">
  A copy-paste-runnable script that authenticates, lists your teams, and sends a payment — start there if you just want working code.
</Card>

<Note>
  This section documents the V1 Legacy endpoints as a **reference for existing integrations**. If you're starting a new integration, use the [B2B API](/api-reference) instead — see the [Migration Guide](/guides/migrating-from-v1) for the V1 → B2B endpoint mapping.
</Note>

## How it works

<Steps>
  <Step title="Before migration">
    Requests to `/v1/*` are transparently forwarded to the original V1 backend. Behavior is identical to calling V1 directly.
  </Step>

  <Step title="After migration">
    The same `/v1/*` requests are served by Rise's new infrastructure. Paths, request fields, and response fields stay the same.
  </Step>

  <Step title="Your integration">
    No code changes required for either phase — the same request produces the same response shape throughout.
  </Step>
</Steps>

## 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:

```json theme={null}
{
  "data": { }
}
```

Errors from request validation use V1's original shape:

```json theme={null}
{
  "error": "Bad Request",
  "message": {
    "type": "invalid_parameters",
    "errors": {
      "wallet": ["Missing parameter wallet"]
    }
  }
}
```

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

```json theme={null}
{
  "error": "Not Found",
  "message": "Team not found"
}
```

<Warning>
  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.
</Warning>

## 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.

<Note>
  This is different from [Authentication](/v1-legacy/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.
</Note>

## Authentication

All endpoints except the SIWE endpoints themselves require a bearer JWT, obtained via `POST /v1/auth/api/siwe` — see [Authentication](/v1-legacy/authentication).

```bash theme={null}
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:

```bash theme={null}
npm install riseworks-sdk
```

```javascript theme={null}
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`.

<Note>
  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](/v1-legacy/authentication) for that flow, since it requires calling `getSiwe`/`verifySiwe` manually.
</Note>

## Endpoint groups

<CardGroup cols={2}>
  <Card title="Authentication" icon="key" href="/v1-legacy/authentication">
    SIWE message generation and signature verification
  </Card>

  <Card title="Payments" icon="credit-card" href="/v1-legacy/payments">
    Instant and batch payments, payment intents, and payment history
  </Card>

  <Card title="Teams & Talent" icon="users" href="/v1-legacy/teams">
    List teams, list/get/remove contractors
  </Card>

  <Card title="RiseID Balance" icon="wallet" href="/v1-legacy/riseid-balance">
    Query on-chain USD balance for a team, user, or company
  </Card>

  <Card title="Invites" icon="envelope" href="/v1-legacy/invites">
    List and send contractor/client invites, including pre-filled (warmed) invites
  </Card>

  <Card title="Troubleshooting" icon="wrench" href="/v1-legacy/troubleshooting">
    Common errors across every endpoint, and how to fix them
  </Card>
</CardGroup>

<Warning>
  These endpoints are supported for existing integrations only and will eventually be deprecated. Plan to move to the [B2B API](/api-reference) when convenient — there's no urgency, but new work should target B2B directly.
</Warning>