Skip to Content
Developer Portal preview — pages marked Draft describe the intended design and are not yet available.
Go to Syper Console
EssentialsAuthentication

Authentication

How requests to Syper prove which application, account, or agent they come from.

DraftDescribes the intended design. Not yet available — names, fields and behaviour may change.

Every request to Syper must identify its caller. Syper distinguishes who is calling (your application or device) from whose account is affected (the account the call acts on).

Caller types

Server applications
Authenticate with a secret API key held only on your backend. Never ship secret keys in browser, mobile, or firmware bundles.
Client applications
Web and mobile apps authenticate the end user and obtain short-lived, scoped credentials through your backend.
Agents and machines
AI agents, robots, and devices authenticate as an Agent Account with their own credentials and limits. See Agent Account.
Telecom sessions
USSD and SMS flows authenticate the subscriber with channel-appropriate factors. See USSD.

Principles

  • Least privilege. Credentials carry only the permissions they need.
  • Environment-bound. Sandbox credentials never work in production, and vice versa. See Environments.
  • Rotatable. Keys can be rotated without downtime. See API Keys.
  • Server-side secrets. Anything that can move money is authorised on a server you control or by Syper — never by an unverified client.

The exact authentication scheme (header format, token lifetimes, signing algorithm) has not been published. It will be documented in the API Reference before release.

Last updated on