Resources
Business, team and access
Read and update the business profile, manage members and invitations, and see the business's webhooks and API keys.
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:
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).
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 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.