Overview
The SDK roadmap explains which VPOS.am libraries and examples should be released after the API contract and webhook lifecycle stabilize.
Why SDKs should follow the API contract
If SDKs are released before the contract stabilizes, the library quickly becomes a compatibility problem. Statuses, errors, webhook payload, idempotency and authorization rules should be fixed first.
Then thin helper libraries can speed up common tasks without hiding important payment lifecycle details.
Which examples are highest priority
For businesses in Armenia, backend examples are the most practical starting point: PHP/Laravel for websites and CRM, Node.js for webhook handlers, Python/FastAPI for internal APIs and integration services.
Separate examples are useful for WooCommerce, OpenCart and custom checkout, but they should rely on the same server-side contract.
How to keep errors transparent
The SDK must not turn every issue into a generic failed state. Integrators need to distinguish validation error, provider timeout, duplicate idempotency key, rejected payment and pending status.
This level of detail helps implement retries, show useful user messages and avoid breaking CRM or ERP workflows.
FAQ
Why should the API contract come before SDKs?
An SDK should follow a stable contract. If statuses, errors and webhook payloads still change, the library becomes a compatibility risk for integrators.
Which SDKs and examples should come first?
PHP/Laravel for websites and CRM, Node.js for webhook verification and Python/FastAPI for internal APIs are the most practical first examples. CMS examples should use the same server-side contract.