Organization & merchant

In PLATFORM_NAME, each merchant account belongs to exactly one organization. The organization holds commercial settings (limits, fees, pricing mode), API credentials, and webhook configuration.

• Dashboard (merchant UI) — You manage the organization while signed in; the browser sends a session token (see Authentication).
• Integrations — Your server uses an API key for hosted checkout and payment retrieval (Authentication).

Dashboard session vs API key

Capability	API key (Authorization: Api-Key …)	Dashboard session (Authorization: Token …)
POST /checkout/create/	Yes	No
GET /transactions/<id>/	Yes	No
Organization profile, API keys, webhooks	No	Yes
Payment links CRUD	No	Yes

Organization profile

Authentication: Dashboard session (logged-in merchant user).

GET /api/organization/
PATCH /api/organization/

• GET — Returns your organization: name, website, contact_email, telegram, price_mode (HT/TTC), read-only limits (min_payment, max_payment, fees, rolling_reserve_*, status, etc.).
• PATCH — Updates editable fields such as name, website, contact_email, telegram, price_mode where allowed.

Organization dashboard snapshot

GET /api/organization/dashboard/

Returns organization summary, wallet summary (if applicable), stats (e.g. user count, transaction count), and recent wallet activity for quick dashboard display.

API keys (merchant)

Manage keys in the dashboard under Organization → API & Webhooks, or via:

GET /api/organization/api-keys/
POST /api/organization/api-keys/
POST /api/organization/api-keys/rotate/
POST /api/organization/api-keys/<id>/revoke/

• GET — Current API key metadata (prefix, scopes, status). The full secret is only shown once at creation or rotation.
• POST — Create the first key for the org (if your product allows a single active key, creation may be rejected when one already exists—use rotate).
• POST …/rotate/ — Replace the active key; response includes raw_key once.
• POST …/revoke/ — Revoke a key by id.

Keys may include an environment field (production or sandbox) in API responses when your deployment issues separate keys.

Webhooks

Configure outbound webhooks (payment status, etc.):

GET /api/organization/webhook/
PUT /api/organization/webhook/
POST /api/organization/webhook/rotate/
POST /api/organization/webhook/test/
POST /api/organization/webhook/test-transaction/

• GET — Webhook endpoint_url and secret preview (not the full secret).
• PUT — Body: { "endpoint_url": "https://your-server.com/webhooks" }.
• POST …/rotate/ — New signing secret; raw_secret returned once.
• POST …/test/ — Sends a sample webhook.test event.
• POST …/test-transaction/ — Body optional { "transaction_id": "<id or TX…>" } to resend transaction.status_changed for a real payment in your org.

Webhook signing and headers are documented in Webhooks.

Public test receiver (optional)

For local tests, the platform exposes a simple ingest endpoint:

POST /api/v1/webhooks/<organization-slug>/

No authentication; useful to confirm connectivity. Verify real integrations using signature validation as in Webhooks.

---

See also: Authentication · Webhooks · Payment links (dashboard)