Skip to main content

Testing with Swagger

Open Swagger API Reference. Its server origin follows the documentation environment.

Application requests​

  1. Create an application key in Console with the required scopes.
  2. Click Authorize and paste the raw key into applicationApiKey.
  3. Do not include the Bearer prefix; Swagger adds it.
  4. Try GET /v1/accounts with accounts:manage.
  5. Follow the Quickstart to upsert an account and send a message.

Authorize does not create an API key. If you lost the secret, create a replacement; Swagger cannot reveal it.

User requests​

  1. Authorize an application key containing users:token_issue.
  2. Call POST /v1/user-tokens with a real account key and stable recipient ID.
  3. Copy the returned access_token.
  4. Paste it into Authorize → userToken.
  5. Try the User Inbox, User Realtime, or User Web Push operations.

Swagger can request a user token because it is calling an authorized API. In a real product, your backend must derive the account and recipient from the signed-in session.

Platform requests​

Only authorized platform operators should fill platformAdminKey. This key can provision tenants, applications, and application credentials through the Admin API. An ordinary integrator does not need it.

Console login uses its own session and is separate from the integration API. Logging in to Console does not fill the Swagger application-key field.

Safe test data​

Use dedicated staging accounts and recipients. Authorization is not persisted after reload, but an authorized Swagger page still holds the secret in browser memory for that session. Provider tests can send real messages; inspect the operation's request schema before executing it.