API Overview
Learn about the API architecture and capabilities
The API is a modern, RESTful API designed to provide comprehensive banking and payment functionality for the Brazilian market.
Architecture
RESTful Design
Our API follows REST principles:
- Resource-based URLs: Each endpoint represents a specific resource
- HTTP Methods: Standard methods (GET, POST, PUT, DELETE)
- Stateless: Each request contains all necessary information
- JSON Format: All data exchanged in JSON format
Base URL Structure
https://api.saq.digital/{version}/{module}/{resource}Example:
https://api.saq.digital/v3/account/5001/balanceAPI Modules
Account Management
Comprehensive account operations including:
- Balance inquiries (real-time and cached)
- Transaction history and KPIs
- PIX key listing
- Webhook configuration
Onboarding
Open an account for an individual (PF) or a company (PJ) by submitting the registration through the API, then start a cadastral update when the deadline expires.
Payment Operations
Full payment capabilities:
- PIX transfers using keys
- Manual transfers with recipient details
- Copy and paste code generation
- QR code payments
PIX Key Management (DICT)
Complete PIX key lifecycle:
- Registration (CPF, CNPJ, email, phone, EVP)
- Verification (OTP for email/phone)
- Deletion
- Ownership claims (portability)
Reporting & Analytics
Comprehensive data access:
- Transaction statements
- Daily balance summaries
- Client information queries
- Export functionality (XLSX)
Webhooks
Real-time event notifications:
- Transaction events
- PIX events
- Account events
- PIX key events
Request Format
Headers
All API requests require authentication headers:
Authorization: Bearer {access_token}
hmac: {hmac_signature}
Content-Type: application/jsonRequest Body
POST and PUT requests include JSON body:
{
"field1": "value1",
"field2": 123,
"field3": true
}Response Format
Success Response
{
"worked": true,
"data": {
"id": 123,
"field": "value"
}
}Error Response
{
"worked": false,
"error": "Descriptive error message",
"error_code": "ERROR_CODE"
}HTTP Status Codes
| Code | Meaning | Description |
|---|---|---|
| 200 | OK | Request successful |
| 201 | Created | Resource created successfully |
| 400 | Bad Request | Invalid request parameters |
| 401 | Unauthorized | Missing or invalid authentication |
| 403 | Forbidden | Insufficient permissions |
| 404 | Not Found | Resource not found |
| 422 | Unprocessable Entity | Validation error |
| 429 | Too Many Requests | Rate limit exceeded |
| 500 | Internal Server Error | Server error |
Pagination
List endpoints use cursor-based pagination:
{
"next": "https://api.saq.digital/v3/resource?cursor=abc123",
"previous": "https://api.saq.digital/v3/resource?cursor=xyz789",
"results": []
}Parameters:
limit: Number of records per page (default: 50, max: 100)cursor: Position marker for pagination
Rate Limiting
To ensure fair usage and system stability:
- Rate Limit: 1000 requests per hour per API key
- Burst Limit: 100 requests per minute
- Headers: Rate limit information in response headers
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 950
X-RateLimit-Reset: 1622547600Data Types
Common Field Types
| Type | Description | Example |
|---|---|---|
| String | Text value | "João Silva" |
| Integer | Whole number | 12345 |
| Decimal | Decimal number | 100.50 |
| Boolean | true/false | true |
| Date | YYYY-MM-DD | "2026-05-29" |
| DateTime | ISO 8601 | "2026-05-29T10:30:00Z" |
Dates and Times (UTC-0)
- Use ISO 8601 with the
Zsuffix for date-times:YYYY-MM-DDTHH:MM:SSZ(e.g.,2026-05-29T10:30:00Z). TheZexplicitly marks the value as UTC-0. - Date-only fields (
YYYY-MM-DD) are also interpreted in UTC-0. - Do not send local time or timezone offsets (e.g.,
-03:00). Convert to UTC-0 before sending. - Timestamps returned in responses are also in UTC-0 (with the
Zsuffix), unless a field is explicitly documented as local time (for example, a companion field such asdate_timepaired withdate_time_utc).
Example — converting from Brasília time (UTC−03:00) to UTC-0:
Local (America/Sao_Paulo): 2026-05-29 07:30:00 -03:00
Send as (UTC-0): 2026-05-29T10:30:00ZCurrency
All monetary values are in BRL (Brazilian Real) with 2 decimal places:
{
"amount": 1000.50
}Documents
Brazilian documents (CPF/CNPJ) can be sent with or without formatting:
{
"document": "123.456.789-00"
}or
{
"document": "12345678900"
}Idempotency
Prevent duplicate operations using idempotency keys:
POST /v3/cashout/create-cashout
idempotency-key: 550e8400-e29b-41d4-a716-446655440000Benefits:
- Safe to retry requests
- Prevents duplicate transactions
- Automatic deduplication
Versioning
The API uses URL-based versioning:
- Current version:
v3 - Version format:
/v{version}/
Example:
https://api.saq.digital/v3/account/balanceVersion Lifecycle:
- New versions announced 6 months in advance
- Old versions supported for 12 months after deprecation
- Breaking changes only in new versions
Environments
Production
https://api.saq.digital- Real transactions
- Real money
- Rate limits apply
Sandbox
https://sandbox-api.example.com- Test environment
- Fake money
- Same API structure
- No rate limits
Best Practices
1. Error Handling
Always handle errors gracefully:
try {
const response = await fetch(url, options);
if (!response.ok) {
const error = await response.json();
console.error('API Error:', error.error);
}
} catch (error) {
console.error('Network Error:', error);
}2. Retry Logic
Implement exponential backoff for retries:
- Retry on 5xx errors
- Don't retry on 4xx errors (fix the request)
- Use exponential backoff (1s, 2s, 4s, 8s)
3. Caching
Cache appropriate responses:
- Balance: cache for 30-60 seconds
- PIX keys: cache for 5 minutes
- Static data: cache for longer periods
4. Logging
Log all API interactions:
- Request details (excluding sensitive data)
- Response status codes
- Error messages
- Response times
5. Security
Protect sensitive data:
- Never log bearer tokens or HMAC signatures
- Use HTTPS only
- Rotate credentials regularly
- Store credentials securely (environment variables)
SDKs and Libraries
Coming soon:
- JavaScript/TypeScript SDK
- Python SDK
- PHP SDK
- Java SDK