API Terms of Use
This page summarizes the authorization, access, rate limits, logging, security and liability framework under the API terms for Podbul API. As of 2026, the current general principles are shared; current agreements and annexes take precedence. This content is for informational purposes.
Scope and Definitions
These terms cover all calls made through the API by applications that connect to Podbul's print-on-demand (POD) and integration flows. The terms “Developer”, “Application”, “API Key/Token”, “Sandbox” and “Production” are the basis for the interpretation of access and usage policies. Podbul API provides versioned endpoints for secure and consistent data exchange with third-party systems. Your application's architecture, usage limits and security measures must comply with these terms.
Authorization and Access
Access is granted via API key or OAuth2-based tokens; scope and role-based authorization is defined according to the minimum authorization principle. Confidentiality, rotation and revocation of keys are the responsibility of the developer; access can be stopped in case of suspicious activity. IP allowlist, mTLS and environment separation (sandbox/production) are recommended to strengthen security. Access to production data should only be done for business justification and valid legal basis.
- Store keys in secret vaults; do not add them to the code repository.
- Rotate key/token every 90 days; cancel immediately in case of leakage.
- Keep sandbox and production credentials separate; narrow access scopes.
- Report suspected unauthorized access to Podbul within a reasonable time.
Rate Limits and Usage Policy
Rate limits are applied for fair allocation of resources; limits may vary by endpoint, plan or application. Exceeding the limit will return a 429 response; exponential backoff should be applied following the Retry-After header. The use of caching, batching and webhooks reduces unnecessary traffic and improves stability. It is recommended to leave a percentage allocation for peak hours in capacity planning.
| Level | Request per minute | Burst | Example Usage |
|---|---|---|---|
| General | 120 | 240 | Standard integrations |
| Partner | 300 | 600 | Peak order scenarios |
| Corporate | Special | Special | High volume, reconciled flows |
- Wait for Retry-After on 429 response; limit repetitions.
- Queue and partition requests; balance the intensity.
- Cache unchanged data; remove unnecessary calls.
- Use webhook/event based triggering instead of polling if appropriate.
Logging and Data Retention
Podbul keeps technical logs such as request-time stamp, IP, endpoint, response code and error details for security and debugging purposes. Personal data minimization in logs is essential; confidential information (password, card, full ID) should not be carried in request paths or logable fields. You can improve traceability by using correlation IDs (e.g. X-Request-ID) in your application. Reasonable retention periods are applied in line with legal obligations and operational requirements.
- Do not send secrets outside the body or as URL parameters.
- Apply anonymization/masking on bugs.
- Protect client logs with access control and encryption.
Safety Obligations
Communication should be done with TLS 1.2+; certificate validation is mandatory and pinning is recommended for critical clients. Input validation, output escaping, idempotent design and fault tolerance are essential for security and integrity. Secret keys should be stored in secure vaults, access should be controlled and the principle of least privilege should be applied. In case of a suspected security incident, immediately revoke affected keys and notify Podbul, preserving the traces.
- Conduct regular security scans for addictions.
- Implement glaze management with environment variables and KMS/HSM.
- Add client-side rate limiting and fallback strategy.
- Ensure legal basis and contractual agreement for data sharing with third parties.
Commercial Usage and Pricing
Commercial use includes situations such as revenue-generating operations in a production environment, high-volume operations or the provision of value-added services to third parties. Such scenarios may require plan/capacity reconciliation, additional contracting or charging. Usage metrics are measured for billing and fair usage policies. Quota upgrade requests may be considered based on technical availability and capacity.
- Example commercial use: E-commerce order synchronization and print flows.
- Example commercial use cases: Multi-tenant integration platforms.
- Example commercial use: Continuous production workloads on internal systems.
- Request capacity in advance in case of unplanned volume increases.
Liability, Misuse and Termination
The developer is responsible for integration accuracy, data integrity and protection of credentials; Podbul tries to provide reasonable continuity of access but does not commit to uninterrupted service. The developer is liable for any consequential damages, loss of data or losses resulting from unauthorized use; applicable mandatory legal provisions are reserved. In case of inappropriate use, access may be suspended or the contract may be terminated. Access may be reopened in a controlled manner when the breach is remedied and the security risk is eliminated.
- Example of abuse: Attempts to circumvent rate limits or over-solicitation by automation.
- Example of misuse: Sharing, selling or publicly storing credentials.
- Example of misuse: Unauthorized data extraction, scraping or exploratory scans.
- Example of abuse: Installing malicious content, injecting or abusing security testing.
- Example of misuse: Processing/transferring personal data without legal basis.
- Trademark and attribution: The Podbul name/signs may not be used in a misleading manner.
To start working with Podbul and start the integration process our application form you can fill it in.