- View and pay outstanding invoices
- See payout slips and track payment history
- Monitor their active subscriptions with live usage estimates
- Add and manage payout accounts (bank transfer or mobile money)
- View and manage saved payment cards
How portal tokens work
A portal token is an opaque 64-character random string that encodes a(org, customer) pair. Monigo validates the token on every request to the portal API.
| Property | Behaviour |
|---|---|
| Scope | Bound to one customer in one organisation |
| Revocation | Instant — delete the token and all requests using it fail with 401 |
| Expiry | Optional. Set expires_at for time-limited links (e.g. one-time email links). Omit for permanent links. |
| Multiple tokens | A customer can have many active tokens simultaneously (e.g. one permanent link + one short-lived email link) |
Generating a portal link
From your backend server (recommended)
Use your API key to generate a portal link server-side. Pass the customer’sexternal_id — the same ID you use when ingesting events.
Time-limited links (for emails)
When sending a portal link in an email or notification, use a short expiry so the link becomes invalid once clicked and acted on.Delivering the portal link
Option 1 — Link in your app (most common)
Fetch a permanent portal link at account creation and store it, or generate it on demand when the customer navigates to their billing settings.TypeScript
Go
Option 2 — Embedded iframe
Embed the portal directly inside your product. The portal is designed to be responsive and renders cleanly at any width.Option 3 — Link in a transactional email
Includeportal_url directly in invoice emails, payment receipts, or dunning messages.
TypeScript
What customers see in the portal
Invoices
Customers can view all finalized, paid, and failed invoices. On finalized or failed invoices a Pay Now button is shown — clicking it redirects to Paystack (or your configured provider) for payment. Once paid, the invoice status updates automatically.Payout Slips
For payout-type plans, customers see their payout slips — the amounts they are owed. They can drill into each slip to see line items, WHT deductions, and the transaction history showing when payouts were sent to their account.Subscriptions
The subscriptions tab shows active and trial plans alongside live usage and an accrued estimate for the current billing period. This lets customers see how their usage is tracking before the invoice is generated.| Field | Description |
|---|---|
plan_name | The name of the plan they are subscribed to |
current_period_start / end | The dates for the billing period in progress |
usage_items | Per-metric usage with estimated charge |
estimated_total | Projected invoice total based on current usage |
Payout Accounts
Customers can add and manage the bank or mobile money accounts that Monigo uses when issuing payouts to them.| Method | Required fields |
|---|---|
bank_transfer | Bank name, bank code, account number |
mobile_money | Mobile money number |
Payment Methods (Saved Cards)
When a customer pays an invoice via Paystack, their card is automatically saved as a reusable payment method. On the next invoice, Monigo charges the saved default card automatically — the customer only sees the portal if the charge fails. Customers can:- View all saved cards (card type, last 4 digits, expiry, bank)
- Set a different card as the default
- Remove a card they no longer want to use
expiring_soon status 30 days in advance, and become expired after their expiry date. Customers receive email notifications for both.
Using the portal API directly (custom UI)
If you want to build your own billing UI rather than using the hosted portal, you can call the portal API endpoints directly from your frontend. Authenticate with theX-Portal-Token header instead of a Bearer token.
Customer info
cURL
List invoices
cURL
Initiate payment for an invoice
cURL
authorization_url to complete payment.
Full endpoint reference
| Method | Path | Description |
|---|---|---|
GET | /api/v1/portal/me | Customer info |
GET | /api/v1/portal/invoices | List invoices (?page, ?limit) |
GET | /api/v1/portal/invoices/:id | Get a single invoice |
POST | /api/v1/portal/invoices/:id/pay | Initiate payment — returns authorization_url |
GET | /api/v1/portal/invoices/:id/transactions | Payment history for an invoice |
GET | /api/v1/portal/bills | List payout slips |
GET | /api/v1/portal/bills/:id | Get a single payout slip |
GET | /api/v1/portal/bills/:id/transactions | Payout history for a slip |
GET | /api/v1/portal/subscriptions | Active subscriptions with live usage |
GET | /api/v1/portal/subscriptions/:id | Single subscription detail |
GET | /api/v1/portal/payout-accounts | List payout accounts |
POST | /api/v1/portal/payout-accounts | Add a payout account |
GET | /api/v1/portal/payment-methods | List saved cards |
PUT | /api/v1/portal/payment-methods/:id/default | Set default card |
DELETE | /api/v1/portal/payment-methods/:id | Remove a saved card |
The portal API only returns documents that are visible to the customer: finalized, paid, and failed invoices. Draft invoices are never exposed. This is enforced server-side regardless of any query parameters.
Managing tokens (list & revoke)
List all tokens for a customer
Revoke a token
Revoking a token immediately invalidates the portal link. Any browser tab or iframe using that token will receive a401 on the next API call.
Security considerations
Keep token generation server-side. Your Monigo API key must never appear in client-side code. Generate the portal token on your server and pass only the resulting URL to the browser. Scope tokens to the minimum necessary lifetime. Use permanent tokens only for in-app links where you control the session. For emails and notifications, setexpires_at to 7–30 days depending on your use case.
Revoke tokens on account deletion or suspension. When a customer closes their account or is suspended, revoke all their portal tokens so they cannot continue to access billing data.
Prefer external_id over UUID in your code. Your customer_external_id (the ID from your own database) is the most stable identifier. Using it avoids having to track Monigo-internal UUIDs in your application.
TypeScript
Integration pattern: on-demand generation
The recommended pattern for most products: generate the portal URL on demand when the customer navigates to their billing section, then redirect or open in a modal/iframe. This avoids storing tokens and ensures the link is always fresh.TypeScript
Go
Related
- Authentication — API keys and how to use them
- Invoice Lifecycle — how invoices move from draft to paid
- Event-Driven Payouts — how payout slips are generated
- Webhooks — listen for
invoice.finalizedto send portal links automatically

