Getting Started
Learn the basics of integrating with the Skyline Digital API
Welcome to the Skyline Digital API
Skyline Digital provides digital asset infrastructure for businesses. The platform enables organisations to manage digital asset transactions and integrate payment rails through a REST API. KYC and KYB verification are completed on the Skyline platform, not through the API.
This guide introduces the core concepts you need to begin integrating with the API: the base URL, authentication methods, request structure, and error handling.
Base URL
The API is available in two environments:
| Environment | API base URL | Platform | Purpose |
|---|---|---|---|
| Production | https://api.skylinedigital.xyz | https://app.skylinedigital.xyz | Live transactions and operations |
| Sandbox | https://sandbox.skylinedigital.xyz | https://skyline-digital-web-staging.onrender.com | Development and testing. The sandbox runs pre-release code and is occasionally reset or unstable; do not rely on it for uptime. |
Accounts and API keys are separate per environment: create a sandbox account and key on the sandbox platform. All API requests use the same endpoints relative to the base URL. The sandbox environment mirrors production behaviour but does not process real transactions.
To request sandbox access, reach out to the Skyline Digital team (see Getting Help below).
Authentication Overview
Integrations authenticate with an API key. You create the key on the Skyline platform, exchange the client ID and secret for a short-lived access token, and refresh it as it expires. Email and password login, two-factor authentication and password management happen on the platform, not through the API. See Authentication and API Keys.
Using the Bearer Token
Once you have obtained a token, include it in the Authorization header of every request:
Authorization: Bearer your-token-here
Request Conventions
| Aspect | Detail |
|---|---|
| Format | JSON request and response bodies. Send Content-Type: application/json |
| Methods | GET reads, POST creates and runs actions, PATCH or PUT updates, DELETE removes |
| Authorization | Authorization: Bearer <access token> on every call except the token endpoint and a few reference lookups |
| Ids | Resources are referenced by their _id, a 24-character hex string. Most fields take an id, not an ISO code. See Setup |
| Dates | ISO 8601, for example 2026-09-28 or 2026-09-28T10:00:00Z |
| Unknown fields | Rejected with 400 property <name> should not exist, in the body and in the query string |
| Responses | The resource itself, with no wrapper. Lists return { "results": [...], "page_total": n, "total": n } |
| Pagination | limit (default 20, maximum 250) and offset. There is no page parameter |
| Idempotency | None. Retrying a POST can create a second resource, so read before you retry |
| Webhooks | None. Poll the resource to follow its status |
| Request id | Every response has an X-Request-Id header. Quote it when you contact support |
Rate Limiting
Limits are set per endpoint, not globally. Over the limit, the API returns 429 (Too Many Requests). Wait before retrying.
| Endpoint | Limit |
|---|---|
POST /auth/token | 30 per minute per client ID and IP address |
POST /auth/api-key/revoke | 5 per hour per user |
PATCH /receivers/{id}, DELETE /receivers/{id} | 20 per hour per user, each |
PATCH /bank-accounts/{id} | 20 per hour per user |
Error Handling
Errors are JSON. Most look like this:
{ "statusCode": 400, "message": ["email must be an email"], "error": "Bad Request" }message is an array of strings for validation errors and a string otherwise. Some errors add fields, such as a code (for example WALLET_NOT_WHITELISTED) or a list of invalidFields. Read statusCode and message first.
| Status | When |
|---|---|
| 400 | Validation failed, an unknown field was sent, or a business rule refused the request. The message says which |
| 401 | The token is missing, expired or invalid. Also used when the user lacks the role for an action, or the organisation's status does not allow it |
| 403 | Not allowed on this resource, for example a view-only member changing a receiver, an unconfirmed account submitting a transaction, or a wallet that has not passed screening |
| 404 | The resource does not exist or is not visible to you |
| 409 | The request conflicts with the resource's current state |
| 429 | Rate limit exceeded |
| 500, 503 | Server error or a dependency is unavailable. Retry later, and quote X-Request-Id if it persists |
Handle 401 by message, not by status alone. Refresh or re-exchange your token only when the message is Unauthorized. These 401 messages do not go away with a new token:
| 401 message | Meaning |
|---|---|
Your user does not have enough permission to perform this action | The user's role in the organisation does not allow this action |
Organisation operational status does not permit this action | The organisation is not active |
No organisation selected for this user | The user has no selected organisation |
Onboarding status is not valid | The organisation's verification is not complete |
2FA session expired. Please login again | The user has two-factor authentication on. See Integration user requirements |
A client that refreshes on every 401 loops on these.
Getting Help
If you run into issues during integration or need access to a sandbox environment, the Skyline Digital team is available to help:
- Telegram: Skyline OTC
- Email: Contact your account manager or reach out through the Skyline Digital platform
For API-specific questions, include your request details (endpoint, parameters, and the error response) to help the team diagnose issues quickly.
What's Next
Now that you understand the API basics, proceed to the Authentication and API Keys tutorial to learn how to obtain and refresh tokens with your API key.