sapiti.net

What It Is

SAPITI is a “Simple API For Ticketing Systems,” positioned as an aggregation API for ticketing systems. Its goal is to let developers access information from multiple modern ticketing platforms through a unified interface. According to the documentation, the project is still at an early stage. It currently supports the Belgian ticketing software UTick first, with plans to add more ticketing platforms in the future while keeping the API definition stable.

Core Capabilities and Developer Experience

Functionally, SAPITI mainly covers the ticketing workflow: accessing agenda/events, managing schedules for specific partners, booking seats for events, and using a Device Id to read events for a specific partner, perform on-site access-control scanning, and print tickets. It provides a test environment at https://sapiti.ovh/v1 and a production environment at https://sapiti.net/v1, plus an unauthenticated /ping/ endpoint for service availability checks.

The API response structure is fairly standardized, consistently returning fields such as success, response, environment, api_version, datetime, cached, status_code, and language; errors also have separate error.code and message fields. The documentation lists status codes including 200, 400, 401, 403, 404, and 500, as well as error codes for invalid JSON, missing parameters, authentication failure, non-existent IDs, and more, which is helpful for development and debugging.

Languages, SDKs, and Ecosystem

For SDKs, the documentation only explicitly provides a PHP Library, hosted on GitHub, with Composer installation support: composer require mediamorphosebe/sapiti-client. Authentication uses a public key, timestamp, and an HMAC-SHA256 signature based on a private key. The timestamp must be within 30 seconds of the server time, giving the security design a relatively clear structure. In terms of ecosystem, only UTick is currently confirmed; other ticketing software has not yet been listed, so its cross-platform value still depends on future expansion.

Pricing and Limits

The captured text does not disclose the pricing model, free quota, rate limits, SLA, payment methods, or contract support options. API access requires the team to provide an Application key or Device Id depending on the use case, suggesting that onboarding may involve manual approval rather than being fully self-service.

Pros, Cons, and Who It’s For

Its strengths include a clear API structure, separate test and production environments, explicit error codes, and convenient PHP integration. It is suitable for development teams that already operate ticketing workflows, need to integrate with UTick, or want to build event booking, ticket validation, or ticket issuing systems. Its drawbacks are also typical of an early-stage project: limited supported platforms, only one SDK language, no clear explanation of self-hosting or closed-source/open-source boundaries, no pricing or service guarantees, and documentation that lacks more complete examples of business endpoints.

Access from China

The documentation does not provide information about access from mainland China, nodes, ICP filing, or payment support, so china_access can only be considered unknown. For teams in China, it is recommended to first test API latency and stability, and to evaluate local ticketing systems or self-built ticketing APIs as alternatives.