# Business, team and access

> Read and update the business profile, manage members and invitations, and see the business's webhooks and API keys.

Source: https://www.ordstage.com/docs/business-and-team/

These endpoints cover the business itself and the people who run it. They follow the same rules as
**Settings** in the dashboard, so a change made through the API looks exactly like one made there.

| Scope | Lets a key |
|---|---|
| `business:read` / `business:write` | Read and update the business profile (`/v1/business`). |
| `members:read` / `members:write` | List members and invitations; invite, resend, revoke, change roles, remove members, send password resets. |
| `webhooks:read` / `webhooks:write` | Manage webhook endpoints, test them, pause them and retry deliveries (`/v1/webhooks`). |
| `api_keys:read` | List the business's API keys (never their secrets). Keys are created and revoked only in Settings. |

## The business profile

`GET /v1/business` answers with the name, website, logo, brand colours, timezone and language customers see.
`PATCH /v1/business` changes only the fields you send:

```bash [curl]
curl -X PATCH https://api.ordstage.com/v1/business \
  -H "Authorization: Bearer $ORDSTAGE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "Nile Clinic Zamalek", "timezone": "Africa/Cairo"}'
```

A logo can be removed (`"remove_logo": true`); a new one is picked by previewing the website in Settings. Every
change sends the `business.updated` webhook event.

## Members and invitations

Changes to the team are made **as the person who created the key**. They must still belong to the business as an
owner or admin when the request is made; otherwise the answer is `403 key_creator_not_allowed`. The usual rules
apply on top:

- Only an owner can make someone an owner or change an owner (`owner_role_required`).
- The last owner can't be demoted or removed (`last_owner`), and the key's creator can't remove themselves.
- Invitations count against the plan's seats (`seat_limit_reached`), and a pending invitation is resent rather
  than duplicated (`invitation_exists`).

```bash [curl]
curl -X POST https://api.ordstage.com/v1/invitations \
  -H "Authorization: Bearer $ORDSTAGE_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"email": "omar@example.com", "role": "member", "name": "Omar"}'
```

The invitation link is emailed to the person and never appears in an answer. In the same way,
`POST /v1/members/{member_id}/send_password_reset` only **emails** the member a reset link; the API never sets,
reads or returns passwords, two-factor settings or sessions.

Events: `member.invited`, `member.invitation_revoked`, `member.role_changed`, `member.removed`.

The sandbox has no team: member lists are empty there, and invitations and password resets answer
`409 not_available_in_sandbox`.

## Webhooks and API keys

`/v1/webhooks` manages the same endpoints as **Settings → Developers → Webhooks**: create (the signing secret is
in that answer only), update, pause, resume, rotate the secret, send a test, list deliveries and retry one. A
replayed create (same `Idempotency-Key`) answers with `secret: null`; rotate the secret if you lost it. See
[Webhooks](https://www.ordstage.com/docs/webhooks/) for payloads and signatures.

`GET /v1/api_keys` lists the keys of the side you call from (live keys for a live key, test keys for a test key)
with their scopes, status and last use, so a system can warn before a key expires.